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Tactical  Aerospace  C^I  in  Coming  Years 

(AGARD  CP-557) 


Executive  Summary 


The  conference  brought  together  representatives  from  MODs,  manufacturers  and  academics  from  most 
of  the  Alliance  countries. 

It  demonstrated  that  major  C3I  developments  for  air  forces  are  underway,  particularly  in  the  United 
States  (Theatre  Battle  Management),  in  France  (SCCOA)  and  at  NATO  (ACCS).  These  C3I  systems 
combine  all  the  real  time  (surveillance,  air  mission  control),  and  deferred  functions  (force  planning  and 
management)  at  a  very  high  level  of  complexity. 

In  effect,  they  constitute  “system  systems”  and  as  such,  justify  the  development  of  suitable 
methodologies.  The  problem  is  to  organise,  manage  and  control  data  flows  between  complex  elements; 
tools  are  being  developed  around  the  programmes  concerned.  Quite  the  opposite  to  the  top-down 
approach,  the  way  in  which  commercially  available  hardware  and  software  is  integrated  into  C3I  has 
been  the  subject  of  much  discussion.  Although  interesting  from  the  cost  point  of  view,  the  use  of  off- 
the-shelf  components  presents  a  number  of  trade-off  problems  with  regard  to  conformity  to  system 
specifications  and  invariably  leads  to  a  cost-efficiency  analysis. 

From  the  technical  point  of  view,  the  first  applications  of  the  real  time  fusion  of  complex  data  were 
presented:  multiradar  tracking,  fusion  of  identification  data,  generation  of  situational  displays  with 
multiple  aircraft  and  targets.  A  variety  of  methods  were  successfully  applied. 

Finally,  future  developments  will  probably  concentrate  on: 

—  the  extensive  use  of  digital  data  links,  with  a  trend  towards  very  wide  bandwidths 

—  the  real-time  application  of  high  resolution  radar  and  optical  sensors  for  observation  of  future 
theatres  of  operations 

—  the  introduction  of  decision  making  aids  for  ops.  planning  and  air  mission  preparation 

—  a  general  trend  towards  real-time  operations  control  minute  by  minute  or  even  by  second,  in  a 
joint  or  combined  forces  context 


Commandes,  pilotage,  communications, 
renseignements,  tactiques  aerospatiaux 
dans  les  prochaines  annees 

(AGARD  CP-557) 


Synthese 


Le  colloque  a  reuni  des  representants  des  Ministeres  de  la  Defense,  des  industriels,  et  des  universites  de 
la  plupart  des  pays  de  T  Alliance. 

II  a  reveld  que  des  developpements  majeurs  de  C3I  pour  les  forces  aeriennes  sont  en  cours,  notamment 
aux  Etats-Unis  (Theater  Battle  Management),  en  France  (SCCOA)  et  a  I’OTAN  (ACCS).  Ces  C3I 
federent  toutes  les  fonctions  temps  reel  (surveillance,  conduite  des  missions  aeriennes)  et  temps  differe 
(planification,  gestion  des  forces)  a  un  niveau  de  complexite  tres  eleve. 

Ils  constituent  en  fait  des  Systemes  de  Systemes,  et  justifient  a  ce  titre  le  developpement  de 
methodologies  adaptees.  Le  probleme  consiste  a  organiser,  maitriser  et  gerer  les  flux  d’information 
entre  des  ensembles  complexes;  des  outils  sont  en  cours  de  developpement  autour  des  programmes 
concemes. 

A  r  oppose  de  I’approche  top-down,  la  maniere  d’integrer  dans  les  C3I  des  produits  hardware  et 
software  du  commerce  a  ete  largement  evoquee.  Interessante  du  point  de  vue  des  couts,  1  utilisation  des 
COTS  pose  des  problemes  de  compromis  dans  le  respect  des  specifications  du  systeme  et  conduit  en 
permanence  a  une  analyse  de  cout-efficacite. 

D’un  point  de  vue  technique,  les  premieres  applications  de  fusion  en  temps  reel  d’ informations 
complexes  ont  ete  presentees  :  poursuite  multiradars,  fusion  de  donnees  d’identification,  generation  de 
situations  aeriennes  composites.  Differentes  methodes  sont  appliquees  avec  succes. 

Enfin,  les  evolutions  dans  I’avenir  semblent  se  concentrer  sur 

_  Putilisation  extensive  de  liaisons  de  donnees  numeriques,  avec  une  tendance  vers  de  tres  larges 

bandes  passantes, 

_  la  mise  en  oeuvre  en  temps  reel  de  capteurs  optique  et  radar  a  haute  resolution  pour  1  observation 

du  theatre  d’ operations, 

—  I’introduction  d’ aides  a  la  decision  pour  la  planification  des  operations  et  la  preparation  des 
missions  aeriennes, 

_  et  d’une  maniere  generate,  vers  la  conduite  des  operations  en  temps  reel  a  I’echelle  des  minutes, 

voire  des  secondes,  dans  un  contexte  interarmees  et  interallies. 
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Theme 

C^I  Systems  are  defined  as  an  integrated  system  of  doctrine,  procedures,  organization,  personnel,  equipment,  facilities,  and 
communications  to  provide  authorities  at  all  levels  with  timely  and  accurate  data  to  plan,  direct,  coordinate  and  to  control 
their  operations  and  crisis  mobilization  and  combat.  The  present  CT  systems  with  all  their  imperfections  and  deficiencies, 
have  been  developed  based  on  the  confrontation  of  massive  forces.  The  recent  events  in  the  Persian  Gulf  have  shown  that  the 
existing  systems  have  certain  deficiencies.  As  progress  is  made  with  Arms  Control  and  Conventional  Force  Reduction  in 
Europe,  the  defense  and  safety  of  Europe  will  have  to  depend  more  and  more  on  technical  superiority  and  sustainability.  It 
appears  that  successful  execution  of  wars  and  conflicts  in  the  future  will  require  the  latest  systems  for  remote  sensing, 
aerial/space  observation,  data  transfer,  data  fusion  and  dissemination,  interoperability  between  systems,  and  Command  and 
Control  capabilities.  In  other  words,  a  decisive  advantage  will  be  gained  by  that  side  who  can  deploy  and  manoeuver  its 
smaller  and  flexible  forces  by  employing  systems  to  provide  early  warning  and  intelligence  and  who  can  rapidly  process  and 
fuse  the  information  and  deploy  it  to  the  correct  Command  and  Control  structures. 

The  topics  covered  addressed  the  new  requirements  for  C^I  structures  in  the  coming  decades  and  the  application  of  the  most 
modem  techniques  and  technologies  such  as  AI  for  rapidly  and  reliably  collecting,  processing  and  fusing  information  and 
making  available  to  the  Commander  decision  options.  Some  of  the  topics  of  interest  are  the  following: 

—  Threat  perception  in  the  coming  decades  (uncertainty  in  aims,  scope,  time  and  location). 

—  Assessment  of  the  capabilities  and  potential  development  of  present  systems. 

—  Advanced  situation  assessment  (sensor  data  fusion  for  intelligence  and  generation  of  air  picture,  including 
identification  of  friend  and  foe). 

—  Decision  aids  for  planning,  tasking  and  execution. 

—  Communication  techniques  and  network  (MIDS,  . ). 

—  Standards,  Open  System  Architecture  (OSA),  man-machine  interfaces. 


Theme 

Les  systemes  CT  peuvent  etre  definis  comme  des  systemes  integres  de  doctrine,  de  procedures,  d’ organisation,  de  personnel, 
d’equipements,  d’ installations  et  de  communications  destines  a  foumir  aux  autorites  a  tons  les  niveaux,  des  donnees  precises 
et  pertinentes,  permettant  la  planification,  la  conduite,  la  coordination  et  le  controle  des  operations,  ainsi  que  la  mobilisation 
en  situation  de  crise  et  de  combat. 

Les  systemes  CT  actuels,  avec  leurs  imperfections  et  defauts  ont  ete  developpes  en  vue  de  la  confrontation  de  forces 
massives.  Les  evenements  recents  dans  le  Golfe  Persique  ont  demontre  que  les  systemes  actuels  ont  certaines  deficiences. 
Avec  la  maitrise  des  armements  et  la  reduction  des  forces  conventionnelles  en  Europe,  la  defense  et  la  securite  de  1’ Europe 
dependront  de  plus  en  plus  de  leur  superiorite  technique  et  de  leur  capacite  de  soutien.  II  semblerait  que  la  conduite  des 
guerres  et  des  conflits  a  I’avenir  exigera  la  mise  en  oeuvre  des  derniers  systemes  de  teledetection,  d’ observation 
aerienne/spatiale,  de  transfert  des  donnees,  de  fusionnement  et  de  diffusion  des  donnees,  d’interoperabilite  entre  systemes  et 
de  commandement  et  controle. 

Autrement  dit,  un  avantage  decisif  est  a  prendre  par  le  camp  qui  saura  deployer  et  manoeuvrer  des  forces  reduites  et  plus 
flexibles  a  I’aide  de  systemes  d’alerte  avancee  et  de  renseignement,  et  qui  sera  en  mesure  de  traiter  et  de  fusionner  les 
donnees  rapidement  pour  les  transmettre  aux  structures  de  commandement  et  de  controle  appropriees. 

Les  sujets  presentes  couvriront  les  nouveaux  besoins  en  structures  C^I  pour  les  decennies  a  venir,  ainsi  que  T application  des 
dernieres  techniques  et  technologies  telles  que  ITA  pour  la  collecte,  le  traitement  et  le  fusionnement  rapides  et  fiables  des 
informations  et  la  mise  a  disposition  d’ options  decisionnelles  pour  le  commandant. 

Parmi  les  sujets  traites  on  distingue: 

—  la  perception  de  la  menace  dans  les  decennies  a  venir  (incertitudes  concemant  les  objectifs  operationnels  et  leur 
localisation  spatio-temporelle). 

—  revaluation  des  capacites  et  revolution  potentielle  des  systtaes  actuels. 

—  revaluation  avancee  de  la  situation  (fusionnement  des  donnees  senseur  pour  le  renseignement  et  1’ elaboration  de  la 
representation  de  la  situation  aerienne,  y  compris  ITFF). 

—  les  aides  a  la  decision  pour  la  planification,  la  repartition  des  taches  et  1’ execution. 

—  les  techniques  et  les  reseaux  de  communication  (MIDS  ...) 

—  les  normes,  r  architecture  des  systemes  ouverts  (OSA),  les  interfaces  homme-machine. 
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TECHNICAL  EVALUATION  REPORT 

Michel  Crochet 
Director ,  Systems  Programs 
Aerospatiale  Espace  et  Defense 
Route  de  Verneuil ,  78133  Les  Mureaux  ,  France. 


1)  Overview 


The  Agard  Mission  Systems  Panel  3rd 
Symposium  on  Tactical  Aerospace  C3I  in 
coming  years  was  held  in  Lisbon  ,  Portugal 
from  15  to  18  may  ,  1995  The  meeting  was 
chaired  by  Mr  Jacques  Cymbalista  from 
France  with  Mr  Bruno  Mazetti  from  Italy  as 
deputy  .  192  representatives  from  14  nations 
attended  the  symposium  .  The  audience  was 
composed  of  representatives  from  the  military 
community  (  MOD'S  and  Forces  )  ,  from 
government  agencies  ,  from  university  and 
from  industry  ,  by  far  the  most  numerous  . 

The  Symposium  occurred  at  a  time  when  the 
geopolitical  context  ,  namely  the  increase  of 
crisis  situation  since  the  end  of  the  Cold  War , 
impulses  many  C3I  activities  in  the 
Government  agencies  and  in  the  Industry  . 

In  the  first  keynote  address  ,  Pr.  Fernando 
Carvalho  Rodrigues  from  Portugal  addressed 
the  role  of  small  satellites  as  support  elements 
to  C3I  systems . 

As  a  matter  of  fact  ,  the  development  of  Low 
Earth  Orbit  applications  ,  using  sophisticated 
.though  light  satellites  tightly  coordinated  in  a 
C3!  network  will  be  a  major  trend  in  the  next 
years  :  the  civilian  programs  such  as 
Globalstar  or  Iridium  ,  for  handheld 
communication  will  be  a  key  to  integrated 
battlefied  concepts  such  as  ’'C4I  for  the 
Warrior  "  (  it  may  be  reminded  that  Agard 
sponsored  a  conference  on  Tacsats  for 
Surveillance  ,  Verification  and  C3I  in  1992) 

The  spectrum  and  the  coverage  of  the 
presentations  were  very  large  and  most  of  the 
key  questions  .  issues  ,  and  achievements 
relevant  to  the  Tactical  Aerospace  C3I  were 
addressed  by  the  authors  . 

As  far  as  the  coming  years  are  concerned  , 
the  meeting  demonstrated  that  the  Nato 


community  Is  working  within  the  frame  of  two 
overlapping  schedules : 

-year  2000  or  so  is  a  first  milestone  to 
provide  the  Nato  Air  Forces  with  an  integrated 
set  of  systems  ,  to  perform  surveillance  and 
identification  within  the  airspace  ,  to  manage 
the  resources  ,  and  to  plan  ,  prepare  and 
control  the  missions  .  Major  programs  are 
going  on  or  under  preparation  : 

-  the  NATO  Air  Command  and  Control 
System  (ACCS)  was  briefed  by  the  NACMA 
General  Manager  ;  year  2001  will  see  the 
completion  of  a  first  level  of  operational 
capability  for  the  system  ; 

-the  french  Air  Force  and  the  French 
MOD  described  the  SCCOA  (Systeme  de 
Commandement  et  de  Conduite  des 
Operations  Aeriennes)  ,  the  development  of 
which  is  underway  since  1992  with 
incremental  delivery  of  equipment  and 
integrated  C2  centers  from  1996  to  beyond 
year  2000 ; 

-the  USA  presented  the  effort 
underway  for  the  development  of  TBM 
(Theater  Battle  Management)  ,  a  follow-on  to 
CTAPS  (Contingency  Tactical  Air  Force 
Planning  System) . 

A  common  feature  of  these  systems  is  that 
they  are  actually  Systems  of  Systems  , 
federating  high  level  functions  and  equipment 
in  a  comprehensive  architecture  . 

One  key  reason  is  the  development  of 
combined  ,  joint  operations  ,  a  major  lesson 
from  Desert  Storm  and  from  the  geopolitical 
situation  that  follows  the  collapse  of  the 
Warsaw  Pact . 

The  need  for  Combined  Operation  Centers 
(CAOCs)  derives  from  the  combination  of  all 
defensive  ,  offensive  and  support  operations  , 
under  a  single  theater  commander  who  plans 
and  controls  the  missions  In  the  airspace  ;  his 
authority  and  responsibility  ,  not  only  on 
national  Air  Force  elements  but  on 
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multinational  Air  Forces  ,  Navies  and  Armies 
assets  drives  requirements  for  communication 
,  shared  procedures  and  for  time  phasing  ; 
hence  an  intricated  architecture  mixing 
surveillance  ,  airspace  management ,  air  traffic 
control  ,  force  management  ,  air  mission 
control  and  C2  resources  allocation. 
Intelligence  of  course  fuels  the  process  . 

A  second  major  trend  is  the  push  towards 
mobile  configuration  ,  rather  than  (or  in 
parallel  with)  a  fixed  architecture  , 

The  ACCS  has  been  switching  from  a  fixed  , 
backbone  architecture  in  Central  Europe 
(designed  during  the  Cold  War  era)  ,  to  a 
Deployable  ACCS  Component ,  more  flexible 
and  able  to  conduct  "out  -  of  -  area" 
operations.  The  french  SCCOA  system  is 
made  of  both  a  fixed  and  an  air  transportable 
architecture  ,  and  the  US  TBM  is  basically 
dedicated  to  unpredictable  theater  operations  , 
and  therefore  flexible . 

Interoperability  is  the  key  word  for  systems 
that  shall  be  able  to  share  and  process 
information  .  often  in  contingency  operations  , 
i.e  under  circumstances  that  were  not 
preplanned  .  It  is  therefore  mandatory  that 
Nato  nations  develop  systems  that  are 
basically  interoperable  in  order  to  allow 
connectivity  ;  but  this  is  not  enough  ,  since 
interoperability  requires  common  doctrines 
and  common  procedures . 

The  use  of  commercial  equipment  (hardware 
or  software)  -  COTS  (for  Commercial-Off-The- 
Shelf)  should  help  interoperability  ,  since  the 
commercial  subsets  focus  towards  single  (or  at 
least  compatible)  standards  Generally 
speaking  ,  the  dramatic  increase  in 
performance  level  ,  along  with  the  collapse  of 
the  cost  ,  of  commercial  hardware  and 
software  is  driving  the  burst  of  the  information 
systems. 


-years  2005  to  2010  might  be  the  second 
milestone  for  aerospace  C3I  :  the  issue  would 
be  then  to  take  advantage  of  all  and  any 
assets  on  the  theater  in  a  distributed 
architecture . 

A  comprehensive  overview  from  the  Mitre 
Corporation  described  the  infosphere  ,  a 
complex  combination  of  all  pieces  of 
information  available  on  the  theater ,  from  the 
fusion  of  all  sensors  data  ,  let  them  be  space-, 
air-  or  ground-based . 

In  the  same  time  ,  the  weapons  are  tightly 
embedded  in  a  loop  of  information  ,  action  and 
assessment .  As  the  capability  and  accuracy  of 


the  weapons  increase  ,  the  need  for  more 
sophisticated  information  (namely  images)  and 
for  shorter  processing  and  transmission  delay 
becomes  more  stressing  Information 
highways  are  then  mandatory  ;  another 
presentation  demonstrated  the  capabilities  for 
high  data  rate  transmission  using  the 
Asynchronous  Transfer  Mode . 

On  the  other  hand  ,  the  intrication  of  capturing 
the  proper  near  real  time  accurate  information 
to  feed  the  decision  process  and  the  weapon 
systems  was  addressed  in  three  presentations 
:  one  demonstrates  the  availability  of  high 
grade  real  time  ground  surveillance 
information  using  airborne  sensors  (  the 
Horizon  helicopter-borne  radar  system); 
another  depicts  the  stategies  that  are  needed 
to  manage  optimally  multiple  spacebased 
intelligence  sensors  ;  the  third  describes  real 
time  algorithms  for  updating  and  planning  in 
real  time  search  patterns  for  precision 
terminally  guided  missiles . 

The  issues  that  are  opened  by  this  trend  to 
cooperative  engagement  of  highly  accurate 
weapons  fed  in  real  time  by  large  size  pieces 
of  information  are  numerous  .  We  propose  in 
the  recommendations  for  future  efforts  that 
some  of  them  be  addressed  in  the  prospects 
of  the  Mission  Systems  Panel . 


A  summary  of  the  main  discussions  and 
conclusion  will  now  be  presented  according  to 
the  breakdown  of  the  sessions  of  the 
symposium  :  (1)  Architecture  ,  requirements 
and  trends  ,  (2)  Situation  assessment  ,  (3) 
Decision  aids  for  planning  ,  tasking  and 
execution  ,  and  (4)  Techniques  and 
technologies . 


2)  Architecture  ,  requirements  and 
trends 

The  presentations  of  major  developments 
going  on  in  Nato  nations  or  under  the  auspices 
of  the  dedicated  Nato  Agency  ,  the  NACMA  , 
addressed  the  issues  that  underly  the  new 
concept  of  a  total  Aerospace  C3I  design  ; 

-the  size  and  criticalness  of  the  information  to 
be  processed  ;  the  french  Air  Force  reminded 
that  as  many  as  10000  aircraft  (civilian  and 
military)  use  its  national  airspace; Europe  is 
actually  a  choke  point ,  and  the  military  C3  has 
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to  interoperate  with  the  civilian  organisation  , 
at  least  in  peace  and  crisis  time  ,  i.e  the 
driving  situation  after  the  cold  war  era  . 

-the  design  of  systems  federating  extremely 
complex  subsystems  that  must  interoperate. 
The  notion  of  system  of  systems  was  opened  , 
along  with  the  tools  it  requests  . 

The  specification  of  a  system  of  system  must 
be  accurate  enough  to  make  sure  that  it  will 
fulfill  the  operational  requirements  ,  but 
flexible  enough  to  let  freedom  to  the 
subsystems  developpers . 

MITRE  presented  methodologies  to  derive  the 
requirements  :  a  top-down  ,  layered  roadmap 
to  identify  the  relationships  and  data 
exchanges  between  the  players,  and  relying 
on  functional  analysis  ,  data  management  and 
integrated  systems  engineering  environment 
models  .  Flexibility  is  critical  to  match  new 
situations  ;  "what  if  ?"  is  a  question  at  the  hub 
of  the  process . 

System  of  systems  deal  mainly  with  the 
interoperability  issue  ,  i.e  with  the  ability  to 
make  subsets  work  together.This  requires  a 
common  will  to  share  the  doctrines  ,  the 
procedures  and  the  data  exchanges  ;  it  is 
therefore  as  much  a  political  issue  within  the 
organizations  ,  as  a  technical  issue  .  It  was 
pointed  out  that  the  US  Air  Force  has  set  up  a 
Forum  of  Principals  (  i.e  an  executive  panel  ) 
in  charge  of  resolving  the  Issues  .  Similar 
procedures  are  implemented  in  other 
organizations . 

Another  critical  trend  is  the  growing  use  of 
commercial  products  (COTS)  .  The  push  from 
low  cost  and  high  performance  level  is 
obvious  :  but  military  systems  must  fulfill 
specific  requirements  (  basically  environment , 
security  ,  maintenability  ...)  that  are  not 
necesseriiy  requested  for  commercial 
products. 

Clearly  ,  there  is  a  gap  in  the  methodology  ,  to 
drive  the  trade-  offs  between  two  trends  : 

-design  and  select  according  to  a  top 
down  approach  ,  that  may  reject  COTS  that  do 
not  prove  their  ability  to  fully  fulfill  the 
requirements  (  or  spend  money  to  demonstrate 
the  qualification  of  the  COTS  to  the  system 
requirements  ) 

-make  extensive  use  of  COTS  ,  betting 
that  they  are  not  too  far  from  the  goals  ,  and 
solve  the  potential  issues  as  they  rise  .  The 
initial  cost  is  obviously  much  lower  but  critical 
issues  may  emerge  on  the  field  . 


Several  examples  where  given  ,  for  hardware 
and  for  software  .  No  actual  recognized 
methodology  is  implemented : 

-  As  far  as  hardware  is  concerned  , 
good  sense  is  driving  and  examples  were 
shown  of  systems  developed  in  very  short 
timeframes  (a  few  months)  that  proved  to  work 
very  well  ,  using  adapted  environment  devices 

-Integrating  commercial  software 
reqires  tools  ;  none  seems  to  be  definitely 
agreed  ;  CORBA  was  presented  as  promising 
but  immature . 

A  (so  far)  good  conclusion  was  proposed  : 
due  to  the  availability  of  COTS  ,  "the  system 
requirements  should  be  defined  in  a  broader , 
less  rigid  fashion;they  should  be  examined  and 
reviewed  ,  but  the  existence  of  commercial 
technology  should  never  be  used  to  cause  the 
capitulation  of  valid  requirements" 

Nevertheless  ,  the  very  large  C3I  systems 
needed  for  aerospace  purposes  have 
generated  a  need  for  a  new  methodology  ,  one 
step  above  the  classicaF  system  engineering 
process  .  They  manage  more  information  from 
more  sources  and  with  more  men  in  the  loop 
than  current  systems  ;  interoperability  in 
changing  environments  call  for  flexibility 
whereas  they  are  usually  embedding  already 
existing  systems  or  components  that  are  not 
flexible . 

Therefore  ,  methods  and  tools  shall  be 
developped  to  help  the  derivation  of  the  right 
level  of  requirements  at  system  of  system 
level  ,  mainly  :  exchange  flows  ,  interfaces  , 
common  procedures  and  standards  ,  and 
ilities . 


3)Situation  Assessment 


The  assessment  of  the  situation  requires  the 
generation  of  an  Air  Picture  from  the  various 
sensors  (active  or  passive)  and  of  a  Ground 
and  Maritime  Picture  ;  as  mentioned  earlier  , 
the  systems  currently  under  development  till 
year  2000  deal  merely  with  the  former  ,  as 
much  work  is  underway  to  provide  the  forces 
with  the  latter  between  years  2000  and  2010. 

The  Air  Picture  is  derived  from  the  data 
generated  by  various  radars  and  passive 
(ESM)  sensors  .  The  main  issue  is  the  data 
fusion  from  these  sources  to  merge 
information  and  enhance  the  quality  of  the 
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Recognized  Air  Picture  (RAP)  under  any 
circumstances  (  saturation  ,  jamming  , 
maneuver  of  the  targets  ...).  The  RAP 
encompasses  detection  ,  track  generation 
and  identification . 

Several  presentations  were  dedicated  to 
multisensor  data  fusion  for  non  cooperative 
targets(  i.e  the  fusion  of  detection  information). 
It  shows  that  algorithms  have  been  derived 
and  work  ,  based  upon  the  Bayesian  theory 
(multiradar  tracking  is  fielded  in  the  current 
versions  of  the  french  STRIDA  system  and  has 
been  proven  and  validated) . 

Other  algorithms  based  on  Fuzzy  Logics  and 
the  Theory  of  Evidence  have  been  presented 
for  application  to  the  target  recognition 
problem  ;  their  features  may  apply  according 
to  the  nature  of  the  a  priori  knowledge  of  the 
targets  ;  it  seems  however  that  the  Bayesian 
algorithms  are  still  the  most  commonly  used  . 

The  use  of  passive  sensors  needs  powerful 
algorithms  to  derive  range  information  and 
continuous  track  data  .  Norway  presented  an 
enhancement  of  the  RAP  generation  using  this 
method  that  seems  promising  . 


The  second  function  of  the  air  picture 
generation  is  the  identification  process  .  The 
principles  and  the  current  applications  of  the 
NIS-IDCP  concept  were  briefed  in  several 
papers  .  Still  using  bayesian  estimates  ,  the 
fusion  of  several  sources  was  described  as 
feasible  and  working  well .  Examples  ,  namely 
from  the  french  companies  ,  demonstrated  that 
fusion  of  identification  is  already  implemented 
not  only  at  Air  Force  level  but  also  between  Air 
and  Army  forces  in  an  Air  Land  Operations 
environment . 

Target  recognition  using  range  resolution  (i.e 
wide  band  signals)  .  and  based  on  the  target 
shape  ,  was  proposed  .  The  question  then  is 
which  air  defense  radar  (except  for  SAM 
engagement  radars)  could  be  available  to 
perform  this  feature  against  aircraft  ,  and 
when. 

The  range  (  and  range  rate)  resolution  is 
indeed  a  key  to  discrimination  techniques  ,  a 
challenge  to  Extended  Air  Defense  (  i.e 
defense  against  theater  ballistic  missiles  ,  for 
which  debris  and  decoys  hinder  significantly 
the  engagement  process)  .  But  this  topic  was 
not  addresed  during  the  symposium  . 

The  generation  of  low  altitude  RAP  ,  the 
enhancements  to  the  AWACS  ,  the  use  of 
passive  or  active  IR  information  was  not 
addressed  either . 


4)  Decision  Aids  for  Planning  , 
Tasking  and  Execution 

The  planning  and  tasking  functions  (that  are 
non  real  time  operations)  are  the  hart  of  the 
aerospace  C3I  systems  under  development . 

The  examples  briefed  show  that  large  software 
for  mission  planning  ,  tasking  and  preparation 
are  being  developed  .  They  are  implemented 
on  more  and  more  mobile  equipment  for 
operations  far  from  the  mainland  . 

Ruggedized  equipment  seems  to  be  set  up  , 
starting  from  commercial  standard  PCs  or 
workstations  .  The  experience  demonstrates 
that  it  may  work  provided  some  caution  is 
taken  to  filter  out  the  environment  constraints  . 
As  far  as  software  is  concerned  ,  one  key 
element  is  the  geographical  databases  .  It  was 
recalled  that  there  is  no  actual  NATO  standard 
for  the  databases  ,  but  only  exchange 
standards  .  Open  architecture  make  extensive 
use  of  commercial  software  components  . 
Security  is  one  issue  ,  especially  for  object 
oriented  databases  there  is  some 
contradiction  between  interoperability  and 
security  ;  it  shall  be  managed  through  veto- 
type  procedures  ,  but  security  clearly 
downgrades  interoperability . 

Discretionary  and  mandatory  access  control 
were  reviewed  ,  and  it  was  pointed  out  that  the 
available  commercial  systems  do  not  comply 
to  levels  of  security  beyond  B1  of  the  Orange 
Book  It  opens  a  field  to  additional 
developments  taking  more  care  of  security 
whereas  performance  should  not  be  degraded 
and  access  through  all  languages  (C  ,  C++  , 
02C  and  OQL)  should  be  possible  . 


Tools  were  presented  to  help  the  commander's 
work  on  the  field  ,  such  as  radar  deployement 
organization  ,  and  meteo  data  integration  : 
more  and  more  functions  are  part  of  the 
optimization  and  decision  making  process  in 
the  currently  developped  systems  . 

Looking  to  the  near  future  ,  still  more 
advanced  concepts  were  presented  in  a  US 
paper  for  adaptive  strike  planning  ,  I.e 
updating  en  route  a  strike  force  of  precision 
guided  missiles  to  optimize  its  search  path  . 
This  process  will  become  mandatory  as  the 
action  loop  is  shortened  down  to  minutes 
(instead  of  days  or  even  hours)  ,  including 
fusion  of  surveillance  and  intelligence  data  , 
mission  planning  and  preparation  ,  and 
mission  execution  to  kill  mobile  targets  for 
example . 
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5)  Techniques  and  Technologies 


This  section  addressed  actually  new 

technologies  that  will  impact  the 

implementation  of  the  future  C3l  systems  . 
Intelligence  is  probably  the  area  where  major 
achievements  are  needed  ,  since  it  feeds  the 
process  of  action  on  the  theater  .  Hence  the 
need  for  accurate  ,  flexible  sensors  providing 
excellent  near  real  time  information  . 

Trade-offs  for  radar  satellite  imaging  using 
SAR  radars  were  presented  .  Resolutions 
down  to  1  meter  for  a  20  km  wide  image  was 
claimed  ,  with  an  average  access  time  to  the 
target  of  10  to  36  hours  ,  using  two  satellites 
in  low  earth  orbit . 

A  strategy  to  manage  the  planning  of  space 
based  observation  assets  {  optical  ,  radar  or 
ESM)  was  proposed  by  Aerospatiale  ;  the 
challenge  is  to  provide  as  much  information  of 
a  given  area  in  as  near  real  time  as  possible  . 
it  relies  on  a  comprehensive  analysis  of  the 
mission  reqirements  and  of  the  features  of  the 
systems  involved  In  the  process  .  Optimum 
matching  of  the  capabilities  of  the  set  of 
sensors  with  respect  of  the  mission  goals  is 
determined . 

An  helicopter  borne  MTI  radar  system  for 
battlefield  observation  ,  Horizon  ,  was  briefed 
by  Eurocopter  .  It  allows  obsevation  and 
location  of  targets  moving  at  more  than  6  km/h 
at  a  distance  of  150km  .  It  was  used  during 
Desert  Storm  operations  and  allowed  Apache 
helicopters  to  strike  Iraqi  vehicles  . 

Fast  computing  techniques  were  demonstrated 
by  Portugal  ,  who  built  a  parallel  architecture 
machine  based  on  Multiple  Instruction 
Stream/multiple  Data  Stream  .  1.15  Giga 
events  per  second  can  be  processed  and 
examples  of  application  to  battlefied  dynamics 
and  to  pollution  spread  in  a  river  were 
presented . 

All  the  above  devices  are  information 
generators  .  Communication  shall  support  the 
C31  network  .  Two  papers  addressed  the 
question  : 

-for  near  term  ,  Link  16  will  equip  most 
of  the  platforms  involved  in  the  aerospace  C2  , 
and  progress  is  underway  to  improve  both  the 
terminals  and  the  message  standards  . 
Application  to  the  extensions  of  Air  Defense 
such  as  Theater  Missile  Defense  is  planned  . 

-the  trend  for  the  future  is  to 
aggregate  more  and  more  information  sources 
,  namely  image  ,  that  will  request  adapted 


transmission  media  .  From  the  military  side  , 
Information  Highways  are  mandatory  and  the 
ATM  (  Asynchronous  Transfer  Mode  )  is  the 
most  probable  protocole  to  optimally  use  the 
wide  band  channels  ,  as  it  was  discussed  by 
the  USAF  . 

The  standard  is  now  available  and  was 
successfully  tested  during  exercises  ,  but  a  lot 
of  work  has  still  to  be  done  :  error  correction  , 
network  management  ,  security  ,  data 
compression ,  etc . 


6)Conciusion  and  recommendations 


The  status  of  the  currently  ongoing  activity  on 
aerospace  C3I,  and  many  prospects  were 
addressed  during  the  symposium  . 

The  description  of  the  large  integrated 
systems  under  development  in  NATO  was 
clear;  the  trends  towards  mobility  ,  integration 
of  the  COTS  ,  and  the  relevant  issues  , 
including  security  were  debated  .  The  need  for 
a  methodology  and  tools  to  manage 
interoperability  at  systems  of  systems  level 
was  pointed  out . 

The  status  of  the  technical  challenges  :  fusion 
of  surveillance  and  of  identification  information 
seemed  promising  .  The  consistency  of  the 
efforts  on  databases  management  ,  including 
security  issues  has  to  be  promoted  . 

Some  information  was  provided  on  more  future 
efforts  .  The  integration  of  sophisticated 
intelligence  and  surveillance  data  in  the 
process  appeared  critical  ,  and  examples  of 
systems  (satellites  and  airborne  battlefield 
observation)  were  presented  ;  the  role  of 
modern  communication  systems  for  data 
transmission  was  addressed  and  the  need  for 
wideband  communication  was  stressed  . 

We  may  suggest  recommendations  for 
possible  future  work  and  presentations  under 
the  direction  of  the  Mission  System  Panel ; 

-address  the  integration  of  Aerospace 
C3I  in  the  Extended  Air  Defense  Concept  , 
under  analysis  in  Nato  ;  it  would  lead  to  new  or 
modified  sensor  development  ,  including 
passive  and  active  IR  ,  and  to  review  critical 
timelines  and  C2  organization  . 

-as  a  consequence  ,  critical  issues 
such  as  target  discrimination  would  be 
stressed  as  the  main  issue  of  ballistic  missile 
defense  .  It  will  impact  the  design  of  the 
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surveillance  and  tracking  architecture  and 
sensors  . 

-  the  near  real  time  integration  and 
fusion  of  battlefield  surveillance  and 
intelligence  data  in  the  future  will  open 
questions  about  organization  of  the  C2  :  it 
obviously  modifies  the  current  relationship 
between  planning  ,  tasking  and  execution  of 
the  air  force  mission  ;  it  requests  adapted 
exchange  of  information  and  command  and 
control  responsibilities  between  the  services 
who  will  share  sensors  ,  platforms  and 
information  ;  the  very  short  timelines  from 
sensor  to  shooter  will  require  an  adaptation  of 
the  hierarchical  C2  organization. 


As  a  final  suggestion  ,  it  might  be  worthwile  to 
broaden  the  sources  of  the  communications 
among  the  Nations  ;  several  nations  who  are 
currently  developping  aerospace  C3I  relevant 
to  the  scope  of  the  symposium  did  not 
propose  contributions  ,  that  would  have  still 
enhanced  the  benefits  of  the  meeting  . 
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The  meaning  of  the  expression 
tactical  role  within  military  scenery 
has  extended  largely  during  the  last 
years.  Any  kind  of  intelligence 
activity  or  military  intervention  of 
international  organisations,  when 
necessary,  usually  is  set  up  very 
early  at  the  smallest  sign  of  regional 
instability,  long  time  before  any 
word  of  war  has  been  spoken  out. 
Nevertheless,  recent  history  has 
shown,  that  even  though  crisis  with 
political  and  military  threats  to 
international  order  still  can  develop 
very  rapidly  at  any  time  and  at  any 
place  in  the  world.  Therefore,  the 
tactical  role  of  any  intelligence 
gathering  system  is  starting  to  be 
measured  at  early  stages  of 
potential  conflicts  in  terms  of 
supporting  features  for  the 
fulfilment  of  peacekeeping  and 
peacemaking  operations. 

The  tactical  role  for  a  space  based 
system  can  be  described  with 
respect  to  the  following  four  mission 
objectives.  It  is  interesting  to 
recognise,  that  they  match  with  the 
decisionmaking  cycle  employed  in 
the  Marine  Corps:  Observe,  Orient, 
Decide  and  then  Act  (OODA) 

Environmental  Monitoring 
Treaty  Monitoring 
Crisis  Monitoring 
Precision  Strike 

For  the  case  of  environmental  or 
treaty  monitoring  objectives,  for 
example  the  support  to  verification 
for  the  chemical  warfare 
disarmament,  because  mass 
destruction  arms  production 
projects  are  always  wrapped  in  tight 


security  and  cover-up  measures, 
space-based  imaging  with  polar 
LEOs  is  perhaps  the  last  remaining 
intelligence  gathering  means.  We 
all  know  about  which  kind  of 
resolution  and  technology  we  are 
talking  about.  The  tactical  role  of 
such  a  system  lies  in  the  routined 
global  surveillance  operations  that 
lead  to  confidence  build-up 
processes  between  observing  and 
observed  forces. 

The  efficiency  of  this  system 
depends  highly  on  the  technological 
level  of  the  imaging  sensors  which 
do  require  a  sophisticated  AODCS 
(Attitude  and  Orbit  Determination 
and  Control  System)  and  integrated 
ground  processing  and 
dissemination  infrastructures. 
With  the  world  wide  reduction  of 
military  budgets,  the  Armed  Forces 
are  obliged  to  define  new  ways  of 
doing  their  business.  For  such  kind 
of  global  routine  surveying  missions 
the  subcontracting  of  commercial 
imaging  services,  is  more  and  more 
envisaged  as  a  valid  option  to  keep 
costs  low,  while  more  emphasis  is 
given  to  the  intelligence  processing 
infrastructure  on  ground. 

For  the  case  of  crisis  monitoring, 
when  early  recognition  of  critical 
warnings  such  as  arms  build-ups  is 
necessary,  or  when  it  is  important 
to  determine  capabilities  and 
intentions  of  the  potential  enemy,  or 
finally,  when  the  stage  has  been 
reached  where  military  intervention 
over  precision  strikes  is  the  only 
solution,  then  small  satellites  play 
its  special  tactical  role  in 
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communications,  as  an  electronic 
mailbox  for  logistical  issues  woi'ld 
wide,  or  as  remote  sensing 
platforms  that  can  be  placed  at  any 
time  and  anywhere  with  latest 
technology  and  dedicated  features 
(Area  of  interest  (AOI),  I'esolution, 
spectral  bands,  revisit  time,  refresh 
rates  for  intelligence  information) 
The  key  words  here  are  fast 
deployment,  dedicated  mission  with 
latest  technology  level  and  of  course 
the  affordability. 

Small  satellites  ai-e  not  meant  to 
replace  large  satellites,  but  they  play 
a  integral  role  within  satellite 
constellations  to  support  C3I.  The 
employment  of  data  relay  satellites 
in  the  near  future  multiplies  the 
intervention  possibility  of  small 
satellites.  With  Pegasus  or  Taurus 
like  launchers,  for  example,  which 
are  mobile  launch  vehicles  with 
multiple  small  satellite  capability, 
the  possibility  to  set  up  a  launch  pad 
in  5  days  and  to  integrate  2  small 
satellites  with  the  launch  vehicle 
and  to  launch  within  3  days  gives 
the  possibility  of  specific  AOI 
coverages  with  the  latest  sensor 
technology  and  flexible  orbit  plane 
architectures  that  comply  with  the 
precision  strike  strategies  and  the 
growing  emphasis  on  tactical 
timelines.  Remember  the  tactical 
role  of  the  small  communication 
link  up  satellites  during  the  Desert 
Shield  and  Desert  Stoimi.  They 
worked  as  a  backbone  for  logistical 
issues. 

Today  commanders  want  more. 
They  want  tactical  reconnaissance, 
imagery,  battle  damage 
assessments,  communications  and 
operability,  but  donit  forget,  it  must 
be  affordable!  As  a  crisis  goes 
through  different  stages,  a 
commander  has  time  to  put  the 
hardware  in  position  that  collects 


information,  stores  or  forwards  in  a 
way  so  that  it  can  be  processed, 
analysed,  disseminated  and  finally 
delivered  to  him,  so  that  he  can 
decide  what  to  do.  The  planing  cycle 
for  the  field  takes  normally  one 
week,  while  the  refreshing  cycle  to 
gather  intelligence  information  lies 
between  10  and  20  hours. 

Small  satellites  may  fit  into  these 
constraints  and  the  question  of 
affordability  explains  why  they  are 
getting  increasingly  important. 
They  are  the  only  way  to  have 
continuous  and  affordable  testbeds 
for  new  technologies  and  training  in 
space.  Standardisation,  multi 
purpose  satellite  bus  technology 
with  bolt-on  payload  philosophy  and 
new  integration  concepts  are  being 
developed  that  lead  to  a  reduction  in 
the  acquisition  time,  faster 
construction  and  to  a  higher  space 
quality  technological  level  and 
simpler  ground  operations. 
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INTRODUCTION 

As  the  ongoing  crisis  in  the  former 
Yugoslavia  has  made  clear,  NATO’s 
support  to  crisis  management  operations 
depends  first  and  foremost  on  air  power. 
Effective  use  of  air  power  requires  an 
integrated,  interoperable  command  and 
control  system  that  controls  all  tactical 
air  ojjerations.  A  single  command  and 
control  structure  is  required  to  provide 
the  planning  and  tasking  of  offensive, 
defensive  and  support  air  operations. 

The  system  must  be  flexible  and  able  to 
respond  to  changes  in  priorities  as  the 
crisis  or  conflict  evolves  and  it  must 
provide  a  deployable  capability  to 
support  out-of-area  operations. 

The  NATO  Air  Command  and  Control 
System  (ACCS)  Programme  has  been 
redefined  in  response  to  this  challenge. 

SITUATION  TODAY 

Today  the  NATO  Integrated  Air  Defence 
System,  which  has  served  the  Alliance 
from  the  50’s  provides  command  and 
control  for  defence  air  operations  from 
northern  Norway  to  eastern  Turkey  and 
is  made  up  of  regional  systems  as  shown 
here.  Separate  national  systems  provide 
the  command  and  control  for  offensive 
air  and  support  missions.  During  the 
mid-1970’s  it  was  concluded  that  the 


NATO  Air  Defence  Ground  Environment 
System  (NADGE)  was  quickly  becoming 
obsolete  and  required  radical 
modernization  and  in  1979,  the  Defence 
Ministers  approved  a  programme  to  meet 
the  need  for  an  integrated  Air  Command 
and  Control  System  for  the  full  spectrum 
of  tactical  air  operations;  defensive, 
offensive  and  support. 

EARLY  PLANNING 

To  carry  out  this  programme,  a  team  of 
national  experts  developed  and  produced, 
in  1989,  a  document  called  the  ACCS 
Master  Plan.  The  Plan  was  developed  to 
meet  NATO’s  perceived  needs  at  that 
time.  From  the  start  ACCS  was  to  be  a 
combination  of  NATO  and  national 
assets,  and  included  all  the  surveillance, 
communications  and  information 
exchange  required  for  an  integrated 
system.  The  concept  at  that  time  also 
envisioned  a  large  number  of 
surveillance  sensors,  and  many  fixed 
command  facilities,  most  of  them  housed 
in  bunkers.  Additionally,  the  nations 
experts  also  laid  the  ground  work  for  the 
transfer  of  responsibility  for  the  planning 
and  implementation  of  the  ACCS 
Programme  to  the  new  ACCS  Agency, 
thus  the  NATO  ACCS  Management 
Agency,  NACMA  was  established  in 
January  1991. 
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CHANGES  FOR  THE  90’s 

Since  the  London  Declaration  of  1990, 
the  Alliance  has  steadily  reshaped  itself 
into  a  new  NATO.  NATO’s  new 
Strategic  Concept  was  agreed  at  the 
Rome  Summit  in  1991.  Specifically,  the 
concept  called  for  increased  emphasis  on 
crisis  management  and  peacekeeping  and 
for  increased  co-operation  and  dialogue 
with  the  emerging  democracies  of 
Central  and  Eastern  Europe.  Moreover, 
it  was  recognized  that  NATO  could 
fulfill  its  new  roles  with  smaller,  more 
flexible  forces.  It  took  four  or  five 
reviews  to  reshape  the  ACCS 
Programme  to  keep  it  aligned  with  the 
new  NATO  strategy  and  reduced 
budgets.  Emphasis  is  now  placed  on 
flexibility,  deployability  and 
interoperability.  The  Programme  now 
consists  of  only  a  backbone  of  in-place 
facilities,  and  sensors  which  together 
provide  the  in-place  command,  control 
and  surveillance  capability,  for  peacetime 
and  early  crisis  requirements.  A 
Deployable  ACCS  Component  or  DAC 
has  been  included  to  meet  the  wartime 
requirements,  and  provide  the  flexibility 
to  conduct  out-of-area  peacekeeping 
operations. 

OPERATION  REOUmEMENT 

SACEUR  has  the  responsibility  for  air 
defence  of  NATO  Europe  in  peace,  crisis 
and  war.  This  requires  an  integrated  air 
defence  system  with  appropriate  sensors, 
command  and  control  and  weapon 
systems  to  obtain  and  maintain  a 
favourable  air  situation,  coordinated  as 
necessary  with  maritime  forces.  The 
planning  and  tasking  of  air  operations 
requires  the  integration  of  defensive, 
offensive  and  support  operations  and 
there  needs  to  be  a  single  command  and 
control  system  to  guarantee  the  correct 


employment.  Significant  air 
reinforcements  to  any  crisis  or  conflict 
must  be  matched  with  the  deployment  of 
a  complementary  command  and  control 
capability.  Such  a  deployment  will  be 
most  critical  to  support  NATO 
commitments  or  reaction  forces,  and  to 
support  peace  operations;  including  the 
deployment  of  the  Combined  Joint  Task 
Force  or  any  operation  under  a  Western 
European  Union,  United  Nations  or  other 
mandate  should  such  a  political  decision 
be  made.  The  deployable  capability 
could  also  support  exercises  or  other 
missions  under  the  Partnership  for  Peace 
Programme. 

THE  ACCS  PROBLEM 

Conceptually,  the  long-term  architecture 
of  ACCS  is  shown  here.  The  operational 
requirement  requires  an  integrated  air 
command  and  control  system  which 
permits  a  high  degree  of  interoperability, 
and  which  in  addition,  will  allow 
interoperation  with  other  surveillance 
assets  both  NATO  and  national  and  with 
land  and  maritime  forces.  The  approach 
taken  is  to  establish  a  minimum 
backbone  of  static  command  and  control 
sites  and  sensors  within  Allied  Command 
Europe  together  with  France  and  Spain, 
which  will  provide  for  peace  and  early 
crisis  operations.  It  is  then  planned  that 
the  deployable  ACCS  component  and  the 
NATO  Airborne  Early  Warning  Force 
will  augment  the  backbone  in  any  area  of 
crisis  or  conflict.  The  concept  also 
envisions  the  future  integration  of  the 
Alliance  Extended  Air  Defence 
Capability  against  Tactical  Ballistic 
Missiles  and  Cruise  Missiles  and  the 
integration  of  the  ground  segment  for 
Ground  Surveillance.  Of  course  these 
future  capabilities  depend  on  the  political 
decisions  made  in  these  areas. 
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LEVEL  OF  OPERATIONAL 
CAPABILITY 

To  allow  for  such  a  wide  range  of 
functions,  it  was  decided  to  implement 
an  evolutionary  acquisition  strategy 
which  we  call  Level  of  Operational 
Capability  to  the  extent  allowed  under 
the  NATO  acquisition  procedures.  For 
LOCI;  which  is  the  current 
implementation  programme;  our 
objective  is  to  provide  for  a  timely 
solution  and  one  that  is  affordable  and 
represents  low  technical  risk.  Therefore 
we  have  scoped  the  LOCI  procurement 
specification  such  that  the  solution  can  be 
provided  by  already  proven  technology. 
Our  general  approach  is  to  integrate 
functions  already  automated,  and  use  as 
much  existing  software;  including  COTS 
and  communications  as  possible.  The 
main  challenge  is  to  provide  a  fully 
integrated  system,  fulfilling  the 
requirements  of  modularity,  portability 
and  reusability  through  an  open  system 
architecture. 

ACCS  ARCHITECTURE 

Shown  here  are  the  entities  that  comprise 
LOCI.  We  will  first  acquire  the  system 
software.  Thereafter,  a  number  of  static 
and  deployable  Combined  Air  Operation 
Centres  will  be  established  to 
accommodate  the  planning  and  tasking 
function,  as  well  as  the  coordination  with 
land  and  maritime  forces.  Further,  a 
number  of  static  and  deployable  Air 
Control  Centres  and  surveillance 
facilities  will  be  established  to  control  air 
missions,  using  a  comprehensive 
Recognized  Air  Picture,  based  on  input 
from  static  and  deployable  radars 
including  the  NAEW,  maritime  assets, 
intelligence  and  civil  air  traffic  control. 
Finally,  the  other  entities,  which  are 
national  responsibility  include  the 


national  wing,  squadron,  and  SAM 
operation  centres. 

COMBINED  AIR  OPERATIONS 
CENTRE 

The  Combined  Air  Operations  Centre, 
CAOC  exercises  tactical  command  and 
control  over  allocated  air  assets,  and 
performs  all  air  mission  tasking,  and 
coordination  with  land  and  maritime 
forces. 

AIR  CONTROL  CENTRE/AIR 
CONTROL  UNIT 

The  Air  Control  Centre,  Air  Control 
Unit,  (ACC/ACU),  is  the  real-time  battle 
management  entity.  It  provides  the  real¬ 
time  control  of  air  missions  in  a 
designated  area.  It  provides  Surface  to 
Air  Missile  (SAM)  weapon  preparation, 
and  is  responsible  for  the  co-ordination 
with  NAEW  and  weapon  control 
operations. 

RECOGNIZED  AIR  PICTURE 
PRODUCTION  CENTRE 

The  Recognized  Air  Picture  Production 
Centre  is  responsible  for  producing  and 
disseminating  the  Recognized  Air  Picture 
(RAP).  The  identification  function  along 
with  data  from  non-ACCS  sources,  such 
as  NAEW  and  Air  Traffic  Control  are 
incorporated  at  the  RPC. 

SENSOR  FUSION  POST 

The  Sensor  Fusion  Post  (SFP)  provides 
sensor  management  and  produces  tracks 
from  active  and  passive  sensors. 

OPERATIONAL  VALIDATION 

Following  the  software  acquisition  and 
testing  at  the  System  Test  and  Validation 
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Facility  (STVF),  we  will  conduct 
operational  testing  at  four  operational 
sites  in  Belgium,  France  and  Italy  shown 
here.  The  designation  of  ARS  and 
CARS,  indicates  that  an  ARS  is  the  co- 
location  of  an  ACC,  RPC,  SFP  and  a 
CARS  is  the  co-location  of  a  CAOC, 
ACC,  RPC,  and  SFP. 

DEPLOYABLE  CAOC 

Also  CAOC  Uedem  is  being  configured 
as  a  hybrid  installation  such  that  a 
number  of  the  work  stations  will  be 
provided  in  shipping  containers  such  that 
a  short  notice  deployable  CAOC 
capability  can  be  provided. 

INITIAL  REPLICATION 

Following  operational  test  and  validation 
the  system  will  be  replicated  at  12 
additional  sites  shown  here.  Again  you 
will  notice  that  all  entities  will  be  co¬ 
located  except  for  the  CAOCs  at  Reitan, 
Finderup,  and  Uedem. 

DEPLOYABLE  ARS 

In  addition  to  these  fixed  locations,  we 
will  also  produce  a  deployable  ARS  as 
part  of  the  system  replication. 

INITIAL  CAPABILITY  PACKAGE 

The  estimated  cost  for  software  and 
testing  at  the  STVF  is  about  $152  million 
(38MIAU);  Integration  into  the  four 
validation  sites  is  about  $  140  million 
(35MIAU),  plus  about  $24  million 
(6MIAU)  for  civil  works.  The  12 
replication  sites  are  estimated  at  $288 
million  (72MIAU)  plus  $112  million 
(28MIAU)  for  civil  works.  The 
deployable  entities  are  estimated  at  $100 
million  (25MIAU).  This  represents  $81 
million  to  be  funded  from  the  common 


NATO  Security  Investment  Programme. 
In  addition,  some  $600  million  of 
national  projects  are  in  the  Capability 
Package  for  Wing  and  Squadron 
Operation  Centres;  Air  Operation  Co¬ 
ordination  Centres  and  Surface-to-Air 
Missile  Operation  Centres.  Although 
these  costs  exceed  the  nominal  guidelines 
for  Capability  Packages,  the  North 
Atlantic  Council  approved  the 
Programme  on  11  May  1994.  The 
TBCEs  for  the  software,  STVF  and 
Validation  sites  are  currently  being 
screened  by  the  NATO  Infrastructure 
Committee.  The  only  major  issue  is 
Industrial  Benefit  Sharing.  Assuming 
financial  authorization  we  will  release  the 
IFB  to  industry  before  the  end  of  1995, 
most  likely  in  November,  Contract 
Award  should  take  place  by  early  1997. 


CONCLUSION 

The  initial  ACCS  Capability  Package, 
developed  in  close  coordination  with 
SHAPE,  represents  the  minimum 
military  requirement,  and  is  the  result  of 
several  programme  reviews  conducted 
these  past  years.  The  programme  takes 
account  of  the  outcome  of  the  debate  on 
the  new  Alliance  strategy,  force  and 
command  structure  and  the  fundamental 
review  of  the  infrastructure  programme. 

The  ACCS  architecture  provides 
flexibility  and  modularity  to  enable  the 
system  to  change  or  grow  as  the 
requirements  and  situations  change. 

The  common  software  will  allow  nations 
to  have  a  common  capability,  thereby 
allowing  standard  procedures  to  be 
developed.  ACCS  ensures  that 
SACEUR  will  be  able  to  continue  to 
fulfill  his  air  defence  mission  and  to 
adequately  direct  and  control  other  air 
missions  for  a  wide  range  of  peace  time 


and  crisis  operations.  The  NATO 
integrated  Air  Defence  System  has  been 
a  central  pillar  of  cooperation  among  the 
Alliance  nations  for  many  years  — .  The 
ACCS  programme  continues  this 
cooperation. 
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Le  programme  SCCOA;  le  besoin  de  I’Armee  de  I’Air 
et  son  developpement  technique 

ICA  Naville 

Directeur  de  Programme  SCCOA 
DCAe  —  SITE 
129,  rue  de  la  Convention 
75731  Paris  Cedex  15,  France 


La  decision  de  creer  pour  le  SCCOA,  un  programme 
d'ensemble  a  ete  prise  ie  15  fevrier  1989. 

Un  dossier  d'orientation  d'ensemble  a  ete  finalise  le  17 
decembre  1991  et  a  permis  de  lancer  les  premiers 
contrats  SCCOA. 

Une  premiere  etape,  SCCOAl,  a  fait  I'objet  d'un  DLR, 
Dossier  de  Lancement  de  la  Realisation  le  15  fevrier 
1993. 

Apres  I'expose  de  Tofficier  de  programme  sur  les  besoins 
operationnels  de  TArmee  de  fair,  je  vais  vous  presenter 
les  problemes  poses  a  I’ingenieur.  Je  commencerai  avec 
la  description  technique  du  contenu  du  programme  en 
relevant  les  aspects  systemes  qui  motivent  la  creation 
d'un  programme  unique  pour  couvrir  I'ensemble  des  SIC 
de  TArmee  de  fair. 

Je  vais  vous  presenter  ensuite  les  enjeux  methodo- 
logiques  qu'un  programme  d'ensemble  tel  que  le  SCCOA 
peut  presenter  pour  la  DGA  en  tant  que  maitre  d'oeuvre 
et  plus  generalement  pour  ses  concepteurs  et  realisateurs 
que  vous  representez  largement  aujourd'hui. 

Je  voudrais  tout  d'abord  revenir  sur  la  question  : 
Pourquoi  un  programme  unique  pour  I'ensemble  des 
moyens  de  commandement  et  de  controle  au  sol  de 
I'Armee  de  fair  ? 

Le  Colonel  BEAUGNON  a  deja  donne  quelques  bonnes 
raisons  avec  la  nouvelle  organisation  de  I'Armee  de  I'air 
et  I’unicite  du  commandement. 

II  y  a  aussi  des  motivations  a  caractere  plutot  technique 
et  methodologique  qui  ont  conduit  a  prendre  la  decision 
de  1989  de  creer  un  programme  unique  :  logiciels  de 
plus  en  plus  volumineux,  developpement  de  nombreux 
s>'stemes  d'information  et  de  communication,  propres  a 
I'Armee  de  fair,  ou  en  interface  avec  elle.  difficultes  de 
prendre  en  compte  I'existant  et  de  gerer  ses  evolutions  de 
maniere  coherente. 

Je  prends  en  exemple  I'histoire  du  STRIDA.  systeme  de 
traitement  et  de  representation  des  informations  de 
defense  aerienne.  Le  STRIDA  a  ete  cree  dans  les  annees 
60  pour  traiter  les  informations  des  grands  radars  de 
defense  aerienne.  Notons  au  passage  que  des  cette 
epoque  la  notion  de  systeme  d'information  etait  deja 
acquise. 


Nous  avons  raccorde  progressivement  au  STRIDA  les 
informations  des  radars  civils,  puis  celles  des  radars  des 
bases  aeriennes.  Plus  recemment  nous  avons  introduit  les 
liaisons  avec  les  batteries  de  defense  sol-air,  avec  le 
systeme  de  defense  aeroporte  (les  AWACS),  avec  les 
avions  Mirage  2000  par  le  teleaffichage.  Cette  histoire 
illustre  bien  la  croissance  de  la  complexite  des  systemes. 
Elle  montre  aussi  tout  I'interet  d'un  systeme  ouvert  et 
evolutif  pour  pouvoir  accueillir  sans  trop  de  difficultes 
des  extensions  nouvelles. 

Le  contenu  physique  du  SCCOA  se  decompose 
traditionnellement  en  trois  grandes  rubriques  :  les 
moyens  de  detection,  les  transmissions,  I'informatique. 

Cette  planche  presente  les  moyens  de  detection  actuels 
sur  la  colonne  de  gauche  et  a  droite  ceux  qui  pourront 
etre  deployes  a  I'avenir. 

Les  moyens  de  detection  actuels  doivent  etre  modernises 
et  completes.  L'aviation  civile  abandonne  la  detection 
primaire  et  nous  aurons  besoin  dans  certaines  zones 
d'insialler  de  nouveaux  radars  23  cm.  Des  radars  haute 
frequence  trans  horizon  ou  RIAS  pourront  completer  la 
couverture  en  bande  S  et  en  bande  L,  notamment  vis-a- 
vis  des  cibles  a  faible  surface  equivalente  radar.  Pour  la 
basse  altitude,  le  systeme  de  detection  aeroportee  (les 
AWACS)  est  bien  sur  la  piece  maitresse  mais  les 
s\'stemes  sol  garden!  leur  interet  pour  des  zones 
ponctuelles. 

Une  approche  systeme  est  necessaire,  dans  le  domaine  de 
la  detection,  pour  optimiser  la  couverture  radar,  le 
fonctionnement  en  modes  degrades  ou  en  cas  de 
brouillage,  la  protection  contre  les  missiles  antiradars  et 
bien  sur  pour  la  gestion  des  frequences,  surtout  si  Ton 
veut  introduire  des  radars  dans  les  bandes  haute 
frequence. 

A  Tavenir,  si  une  defense  aerienne  elargie  est  constituee, 
les  informations  issues  des  moyens  de  detection  devront 
etre  transmises  au  centre  de  commandement  et  de 
controle  des  operations  aeriennes. 

Les  transmissions  evoluent  vers  des  systemes  a  haut  debit 
et  mieux  proteges  contre  les  compromissions  :  Have 
Quick  II,  UHF  durcis,  le  MIDS-liaison  16.  Des  liaisons 
nouvelles  sont  developpees  pour  relier  les  systemes 
aeroportes  et  les  centres  de  controle  fixes  ou  mobiles. 


Paper  presented  at  the  AGARD  MSP  3rd  Symposium  on  ‘‘Tactical  Aerospace  CH  in  Coming  Years'’, 
held  in  Lisbon,  Portugal  from  15th  May  to  18th  May  1995,  and  published  in  CP-557. 
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Les  aspects  systemes  ne  concement  pas  que  le  SCCOA 
mais  tous  les  systemes  utilisateurs.  Une  bonne 
coordination  est  done  ntessaire  entre  les  differentes 
directions  de  programme  concemees.  Les  reseaux  sol-air, 
par  exemple,  concement  tout  autant  les  aeronefs, 
frangais  et  allies  et  aussi  certaines  plates-formes  de  la 
Marine  et  de  I'Armee  de  terre.  Les  reseaux  de 
transmission  des  bases  aeriennes  seront  modernises.  Bien 
entendu  les  problemes  de  partage  du  spectre 
electromagnetique,  d'allocation  et  de  gestion  des 
frequences  necessitent  des  etudes  systemes  rigoureuses. 

C'est  dans  le  domaine  des  systemes  d'informations  que 
les  aspects  systemes  sont  les  plus  importants  en  volume. 
Ce  domaine  est  encore  appele  traditionnellement 
“informatique*’  dans  notre  vocabulaire,  mais  un  systeme 
d'information  ne  se  reduit  pas  a  un  systeme  informatique, 
comme  chacun  sait. 

La  planche  qui  vous  est  presentee  maintenant  schematise 
i'articulation  de  Tensemble  des  grandes  fonctions  du 
SCCOA  telles  qu'elles  ont  ete  decrites  par  le  Colonel 
BEAUGNON  :  surveillance,  evaluation  de  la  menace, 
gestion  de  I’espace,  gestion  des  forces  et  des  moyens, 
controle  des  missions,  controle  du  trafic,  exploitation  du 
renseignement. 

On  peut  distinguer  deux  boucles  principales  : 

-  une  boucle  que  Ton  peut  qualifier  de  "temps  reel",  avec 
la  surveillance  aerienne  et  le  controle  des  missions, 

-  une  boucle  "commandement"  avec  le  renseignement  et 
Telaboration  de  fordre  de  bataille  ennemi,  I'etat  des 
forces  et  des  moyens,  la  planification,  rattribution,  la 
preparation  des  missions. 

On  voit  que  ces  deux  boucles  sont  tres  interdependantes 
et  qu'il  faut  assurer  leur  interoperabilite,  ainsi  que 
rinteroperabilite  des  differents  systemes  qui  les 
constituent. 

II  est  bien  evident  aussi  que  I’Etat-major  des  Armecs.  la 
Marine  et  I'Armee  de  Terre  ont  besoin  d'echanger  des 
informations  ou  d'envoyer  des  directives,  et  que  des 
interfaces  sont  a  prevoir  a  differents  niveaux. 

L'interopcrabilitc  avec  les  allies,  e'est-a-dire  avec  I’ACCS 
est  aussi  une  demande  incontournablc.  dc  meme  qu'avec 
le  controle  aericn  civil. 

Le  Colonel  BEAUGNON  a  deja  presente  les  principales 
interfaces  du  SCCOA. 

Jc  veux  seulcmcnt  souligner  que  Ic  problemc  des 
interfaces  n'csl  pas  sculemcnt  une  question  dc  standards 
techniques  d'cchangcs,  il  s'agit  aussi  de  nietlrc  au  point 
des  procedures  d'cchangcs  d'informations  ct  mcme 
d'echanges  dc  rcsponsabililcs  cnlrc  des  actcurs,  on 
intement  done  dans  Icurs  methodes  dc  travail,  quand  cc 
n'csl  pas  sur  leur  organisation  interne  ou  Icur  hierarchic, 
Ic  problemc  est  bien  connu  dans  I'industric  lorsquc  Ton 


veut  developper  un  systeme  d'information.  C'est  cela  la 
veritable  interoperabilite.  Aujourd'hui,  cette  inter¬ 
operabilite  est  maitrisee  de  fagon  bilaterale,  de  SIC  a 
SIC ;  il  n'y  a  pas  d'interoperabilite  globale.  Si  Ton  veut 
eviter  de  multiplier  les  interfaces  d'une  maniere 
combinatoire  et  exponentielle,  il  faut  avoir  une  approche 
globale. 

Ou  en  sommes-nous  aujourd'hui  ? 

La  boucle  temps  reel  est  deja  largement  couverte  avec  le 
STRIDA,  mais  le  STRIDA  lui-meme  doit  evoluer 
techniquement,  aussi  bien  pour  renouveler  les  materiels 
que  pour  mettre  a  jour  les  logiciels,  notamment  vis-a-vis 
des  normes  de  qualite  et  des  standards  du  marche. 

Pour  le  reste,  on  a  deja  ponctuellement  realise  certains 
SIC  ainsi  que  plusieurs  systemes  de  preparation  de 
missions,  mais  ces  s>^stemes  restent  parcellaires  et  ne 
couvrent  qu’une  partie  des  besoins.  Il  s'agit  done  de 
continuer  a  developper  les  differents  SIC  concemes  mais 
d’une  maniere  coherente  et  intelligente  si  Ton  veut  en 
final  avoir  non  pas  une  coexistence  difficile  entre  eux 
mais  un  veritable  systeme  de  gestion  de  la  bataille  ou  de 
gestion  de  crises. 

N'oublions  pas  que  la  boucle  de  commandement  existe 
deja,  mais  fonctionne  de  maniere  encore  tres  manuelle,  si 
Ton  peut  dire  (telephone,  telecopie,  transmissions 
d'images  sont  deja  largement  utilises).  Il  s’agit  d'apporter 
les  aides  informaliques  qui  permettront  de  faire  circuler 
I'information  plus  rapidement,  done  d'obtenir  un  temps 
de  reaction  globale  beaucoup  plus  court  et  de  gerer  un 
nombre  ires  eleve  de  missions/jours. 

A  ce  stade  de  I'expose,  je  peux  deja  presenter  une 
s}mthese  des  principaux  axes  de  travail : 

-  donner  a  I'Armee  de  fair  les  moyens  dont  elle  a  besoin 
dans  le  cadre  de  sa  nouvelle  organisation  et  de  ses 
nouvelles  missions,  d'ou  la  priorite  donnee  aujourd'hui 
au  de\’eIoppement  des  moyens  mobiles, 

-  federer  un  existant  considerable,  notamment,  faire 
evoluer  le  STRIDA  vers  une  architecture  modernisee  et 
compatible  avec  I'ACCS, 

-  introduire  des  fonctions  nouvelles  tout  en  assurant  la 
coherence  d'ensemble,  surtout  dans  les  fonctions  de 
commandement, 

-  assurer  rinteroperabilite,  interarmees  et  interalliees  ; 
rinteroperabilite  avec  I'ACCS  est  sans  doute  la 
contrainte  la  plus  structurante  sur  les  fonctions 
operationnelles  et  le  decoupage  des  modules  logiciels. 

COMMENT  FAIRE  ? 

Jc  voudrais  maintenant  vous  presenter  la  methodologie 
que  I'on  a  commence  a  mettre  en  place  a  la  Direction  de 
programme,  avec  I'aide  de  I'Architecte  Industriel,  pour 
gerer  cette  affaire  en  introduisant  dc  la  rigueur,  mais  en 
voulant  restcr  pragniatiquc. 
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Introduire  de  la  rigueur,  c’est  appliquer  les  directives  en 
matiere  de  conduite  des  programmes  d'armement,  avec 
un  decoupage  en  phases  et  jalons.  Mais  il  est  difficile 
d'appliquer  brutalement  ce  concept  pour  traiter 
Tensemble  du  probleme  pose. 

En  fait,  c’est  pour  chacun  des  constituants  du  SCCOA 
que  nous  cherchons  a  appliquer  la  melhode,  et  ces 
constituants  sont  tres  nombreux.  Nous  avons  appele 
“operation  technique”,  etude,  realisation  ou  maintien  en 
condition  operationnelle,  un  ensemble  de  taches  coherent 
entrant  dans  le  cycle  de  vie  d'un  tel  constituant. 

Ces  operations  techniques  sont  regroupees  en  etapes 
coherentes.  Nous  avons  ainsi  une  soixantaine 
d'operalions  techniques  au  titre  de  I'etape  1  du  SCCOA. 
Les  etapes  se  succederont  tous  les  2  ou  3  ans  pour 
realiser  des  versions  successives  du  SCCOA.  Qu'est  ce 
qu’une  etape  ?  Qu'est  ce  qu'une  version  ? 

Une  version  du  SCCOA  forme  un  tout  coherent  sur  ie 
plan  operationnel,  elle  couvre  I'ensemble  du  systemc  et 
determine  le  contexte  d'emploi  de  ses  constituants. 

En  termes  de  qualite  et  de  gestion.  une  version  se 
prepare,  se  specific,  se  qualifie,  a  une  definition. 

En  pratique,  on  passera  d'une  version  a  la  suivaiitc  de 
maniere  progressive  et  controlee  au  plan  du  contenu 
technique,  des  couts  et  des  delais. 

La  realisation  des  versions  successi\'es  se  chevauchcnt 
necessairement  puisqu’on  lance  une  version  tous  les  deux 
ou  trois  ans,  alors  que  le  developpement  de  chaque 
constituant  couvre  une  periode  de  5  a  10  ans. 

Cest  une  maniere  d'appliquer  les  recommandations 
relatives  aux  programmes  a  logiciels  preponderants  qui 
preconisent  le  developpement  ''incremental"  pour  eviter 
les  divergences  inacceptables  entre  les  besoins  des 
utilisateurs  et  la  perception  qu'en  ont  les  realisateurs. 

On  regroupe  done  les  operations  de  maniere  transversale. 
par  etapes :  chaque  etape  regroupe  des  operations 
techniques  : 

-  de  realisation  de  la  version  N. 

-  d'etudes  pour  preparer  la  version  N  +  1, 

-  de  maintien  en  condition  operationnelle  de  la  version 
N-  1. 

Tout  cela  necessite  comme  vous  pouvez  Timaginez  de 
mettre  en  place  une  gestion  de  configuration  adaptce  aux 
besoins  :  au  besoin  de  I'Annce  de  fair  qui  doit  sa\oir  a 
lout  moment  quelle  est  sa  configuration  ou  son  standard 
operationnel  :  au  besoin  du  maitre  d'ouvragc  et  des 
industricis  realisateurs  ou  concepteurs  lorsqu'il  s'agit  de 
preparer  les  contrats  ou  d'aller  iravailler  sur  les 
installations  existantes. 


Les  s>'stemes  C3I  de  I'Armee  de  fair  sont  congus  et 
realises  sous  la  responsabilite  du  Service  Technique  des 
Telecommunications  et  des  Equipements  aeronautiques, 
le  STTE,  qui  s'est  done  vu  confier  naturellement  la 
conduite  du  programme  SCCOA. 

La  maitrise  d'oeuvre  des  realisations  individuelles  est 
confiee  aux  industriels  les  plus  competitifs  ;  pour 
I'ingenierie  globale  du  systeme,  il  a  ete  decide  de  faire 
appel  a  un  architecte  industriel  independant  des  maitres 
d’oeuvres  et  des  r^lisateurs  :  AEROSPATIALE, 

Dans  le  schema  desormais  classique  du  “V" 
methodologique,  I'architecte  industriel  est  responsable  de 
I'architecture  d'ensemble,  il  a  conduit  I'analyse 
fonctionnelle  en  coherence  avec  celle  de  TACCS  ;  cette 
analyse  a  permis  de  decrire  precisement  chacune  des  8 
fonctions  du  SCCOA  que  le  Colonel  BEAUGNON  vous 
a  presentees.  L'architecte  realise  les  conceptions 
systemes  jusqu'aux  specifications  techniques  de  besoin 
globales  des  produits. 

Un  point  que  cette  planche  ne  fait  pas  apparaitre  est  le 
role  de  I'Armee  de  fair.  Si  Ton  veut  eviter  les 
divergences  entre  les  besoins  de  Tutilisateur  et  les 
realisations,  lorsqu'il  s'agit  de  systemes  d'information,  il 
est  indispensable  d'organiser  des  retours  frequents 
(disons  tous  les  6  a  18  mois  ma.ximum).  A  chaque  phase 
du  de\^eloppement,  il  faut  organiser  de  tels  rebouclages. 
Cest  ce  que  certains  appellent  IBO,  illustrateur  de 
besoins  operationnels.  en  phase  de  faisabilite, 
maquettes/prototxpes  en  phases  de  definition  detaillee, 
plate-forme  d'essais  et  d’integration  au  stade  de  la 
realisation.  Ces  rebouclages  ne  sont  pas  prevus 
formellement  dans  I'instruction  sur  la  conduite  des 
programmes  d'armement,  ni  dans  la  planche  qui  vous  est 
presentee  mais  iis  doivent  faire  partie  des  regies  de 
management  d'un  programme  tel  que  le  SCCOA. 

Une  plate-forme  d'integration  a  Mont-de-Marsan,  le 
Centre  de  Developpement.  d’Evaluation  et  de  Validation 
des  Systemes  (CDEVS)  a  ete  d'ailleurs  prevue  pour 
realiser  les  essais  des  sous-ensembles  dans  un 
environnement  operationnel  realiste,  et  pour  valider  les 
grandes  fonctions  du  systeme. 

Lc  programme  d'ensemble  SCCOA.  decompose  en  etapes 
se  succedant  tous  les  2  ou  3  ans.  assure  la  mise  en  place 
ou  la  modernisation  des  sy'stcmcs  dont  a  besoin  I'Armee 
dc  fair : 

-  une  chaine  de  commandement  refondue  qui  integre 
dans  le  CCOA  les  3  composantes  anterieures  de  la 
Defense  acrienne,  de  la  FATAC  et  du  COTAM,  en  lien 
avec  la  nouvelle  organisation  dc  I'Armee  de  fair, 

-  une  composanic  mobile  dc  fonctionnalites  identiques 
aux  centres  fi.xcs,  lc  C3M, 

-  un  STRIDA  renovc.  evoluant  vers  une  architecture 
informatique  modcrniscc  et  compatible  avec  la 
structure  dc  U  pc  ACCS, 
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-  un  centre  commun  SCCO A/ACCS  a  Lyon  Mont- 
Verdun. 

Par  rapport  aux  methodes  traditionnelles  de  gestion  des 
moyens  electroniques  sol  de  TArmee  de  I'air  ou  les 
domaines  de  la  detection,  des  telecommunications  et  de 
I'informatique  etaient  geres  de  maniere  relativement 
autonome,  le  SCCOA  constitue  un  effort  methodologique 
sans  precedent  pour  analyser  de  maniere  s>stematique  la 
coherence  d'ensemble  entre  les  differentes  operations  ; 
coherence  operationnelle,  coherence  budgetaire, 
coherence  technique  et  calendaire. 


Cet  effort  nous  permet  de  developper  un  veritable 
schema  directeur  qui  a  deja  ete  partiellement  realise.  II 
nous  permettra  aussi  de  mieux  maitriser  les  couts 
d'ensemble  du  systeme,  y  compris  les  couts  de  maintien 
en  condition  operationnelle.  Cette  methode  nous  impose 
aussi  de  consacrer  beaucoup  plus  de  temps  qu'auparavant 
a  la  definition  precise  du  besoin  et  des  specifications 
techniques.  Meme  si  cette  methode  semble  devoir 
allonger  les  delais,  dans  la  phase  initiale,  fexperience 
montre  que  I'effort  consent!  au  depart  porte  ses  fruits  au 
stade  des  essais  d'integration  et  de  validation  et  que  c'est 
bien  en  suivant  une  telle  methodologie  qu'on  a  la 
meilleure  chance  de  satisfaire  au  mieux  les  utilisateurs. 


CREATION  DU  PROGRAMME 
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Aspects  prospectifs  des  C3I  Air 


ICA  Desnoes 
Sous-directeur 
DCAe  —  SITE 
129,  rue  de  la  Convention 
75731  Paris  Cedex  15,  France 


Faire  de  la  prospective  c'est,  d'une  maniere  ou  d’une 
autre,  predire  I'avenir,  et  predire  I'avenir  est  toujours  un 
exercice  perilleux ;  mais  c’est  un  exercice  indispensable 
dans  un  monde  qui  evolue  rapidement,  tout  particu- 
lierement  dans  le  domaine  de  I’informatique,  et  done  des 
C3L  Mais  conune  il  faut  plusieurs  lustres  pour  savoir  de 
combien  Ton  a  eu  tort  ou  raison,  le  peril  pour  I'orateur 
n'est  pas  si  grave. 

En  effet,  nous  devons  nous  situer  ici  a  une  echeance  de 
dix  a  vingt  ans,  au-dela  des  periodes  couvertes  par  les 
programmes  dans  leurs  phases  actuelles.  Si  Ton  regarde 
les  echelles  de  temps,  on  observe  qu’il  aura  fallu  de 
I’ordre  d'une  dizaine  d'annees  pour  mettre  vraiment  un 
programme  comme  le  SCCOA  sur  rails  a  partir  de  I'idee 
initiale  (qui  date  de  1986),  et  que  les  idees  d'aujourd'hui 
metlront  aussi  une  dizaine  d'annees  pour  faire  Icur 
chemin,  et  sans  doute  encore  autant  pour  montrer  leur 
reelle  fecondite. 

Je  rappelle  au  passage  que  je  n'exprime  ici  que  des  vues 
personnelles,  que  certains  collegues  m'ont  aide  a 
preciser,  mais  qui  n'engagent  que  moi. 

Avant  de  nous  lancer  dans  des  predictions,  il  faut 
savoir  comment  nous  interpretons  les  caractcris- 
tiques  des  systemes  actuels  et  comment  nous  les 
extrapolons  vers  le  futur,  s'il  y  a  lieu  d’extrapolcr,  car 
certaines  caracteristiques,  que  je  qualifierai 
d'invariants  dynamiques,  restent  stables  malgre  la 
formidable  evolution  des  technologies ;  il  s'agit 
notamment  des  diverses  composantes  de  la  croissance 
de  la  taille  et  de  la  complexite  des  systemes. 

Premiere  caracteristique :  entraines  par  la  croissance 
des  performances  des  materiels,  les  logiciels  sont  de  plus 
en  plus  volumineux  et  contiennent  un  savoir-faire  de 
plus  en  plus  important,  qui  est  en  grande  partie  le  savoir- 
faire  de  I'organisme  utilisateur,  lequel  peut  de  moins  en 
moins  s'en  passer.  Ce  sont  done  des  biens  tres  precieux 
qui  meritent  des  precautions  extremes.  Cela  est  encore 
plus  vrai  dans  I'iniormatique  dite  de  commandement  qui 
est  en  quelque  sorte  une  mise  en  conserve  de  concepts  et 
de  procedures  operationnels  detailles. 

D'ou  une  deuxieme  caracteristique,  amplement 
confirmee  par  I'observation  :  les  logiciels  des  grands 
systemes  informatiques  evoluent  beaucoup  plus  par 
retouches  que  par  grandes  refontes,  car  il  faut  coller  a 


revolution  des  besoins,  qui  est  rapide,  sans  remettre  en 
cause  I'acquis.  Cette  evolution  des  besoins  est 
actuellement  d'autant  plus  rapide  que  I'environnement 
vient  de  changer  et  que  Ton  sait  mal  se  projeter  dans  le 
futur  lointain.  Si  nous  prenons  I'exemple  du  STRTOA, 
qui  vit  depuis  plus  de  trente  ans  a  partir  de  la  meme  base 
logicielle,  nous  observons  qu'il  doit  s'adapter  a 
revolution  des  capteurs,  a  celle  des  telecoihmunications, 
a  celle  de  la  gestion  de  I'espace  et  du  controle  du  trafic 
par  les  civils,  aux  nouvelles  liaisons  tactiques  comme  la 
liaison  16,  aux  nouveaux  aeronefs  comme  le  Rafale,  etc. 
C'est  le  progres,  et  nous  devons  nous  y  associer.  Cette 
evolutivite  est  notamment  traduite  dans  la  demarche  dite 
PALP,  ce  qui  signifie  Programmes  A  Logiciel 
Preponderant,  demarche  formalisee  il  y  a  quelques 
annees  par  la  DEI. 

Troisieme  caracteristique,  deduite  de  la  precedente  ;  la 
situation  actuelle,  ou  nous  devons  mettre  en  place 
beaucoup  de  systemes  C3I  nouveaux,  est  exceptionnelle ; 
lorsque  la  plupart  des  fonctions  auront  ete  correctement 
informatisees,  il  ne  s'agira  plus  en  majorite  que 
d'evolutions,  e'est-a-dire  d'adjonctions  de  complements 
ou  de  modifications  de  petite  taille  par  rapport  a  la  base 
installee. 

Quatrieme  caracteristique  :  I'un  des  enjeux  majeurs  est 
I'interoperabilite  entre  grands  systemes  C3I,  nationaux  et 
allies.  Par  exemple,  le  SICA,  C3I  des  Etats-majors  et 
centres  d'operations  interarmees,  doit  etre  interoperable, 
entre  autres,  avec  le  SICF  de  I'Armee  de  terre,  avec  le 
SYCOM  de  la  Marine,  avec  le  SCCOA  de  I'Armee  de 
I’air.  Le  SCCOA  doit  etre  interoperable  avec  I'ACCS, 
avec  le  SICA,  avec  le  SICF,  avec  le  SYCOM,  avec 
MARTHA,  avec  SENIT,  avec  les  systemes  d'armes 
divers,  dont  les  avions  de  I'Armee  de  fair,  avec 
I'Aviation  civile,  etc.  On  peut  ainsi  identifier  une 
trentaine  de  systemes  potentiellement  en  interface  avec  le 
SCCOA.  Des  s>'stemes  de  ce  type  continueront  a  exister, 
car  le  systeme  de  tous  les  systemes  serait  ingerable  et, 
vision  personnelle,  le  restera  dans  le  futur  previsible. 

Cinquieme  caracteristique :  les  materiels  et  les 
logiciels  de  base  se  standardisent  de  plus  en  plus,  ce  qui 
contribue  a  la  necessaire  perennisation  des  logiciels 
mentionnee  plus  haut.  Les  standards  les  plus  connus  sont 
UNIX  et  ses  derives  comme  POSIX.  Les  interfaces  dc 
communication  se  standardisent  egalement,  s'appuyant 
notamment  sur  le  modele  OSI  de  I'lSO. 


Paper  presented  at  the  AGARD  MSP  3rd  Symposium  on  “Tactical  Aerospace  0J  in  Coming  Years'', 
held  in  Lisbon,  Portugal  from  15th  May  to  18th  May  1995,  and  published  in  CP-557. 
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Sixlcme  caractcristique :  on  trouve  sur  le  marche  de 
plus  en  plus  d'outils  logiciels,  que  Ton  peut  encore 
appeler  produits  logiciels  ou  composants  logiciels.  Ces 
composants  sont  en  general  disponibles  sur  les  grands 
standards  du  marche  et  permettent  d'economiser  sur  le 
developpement  des  applications  et  de  beneficier  de 
services  elabores  con9us  par  les  meilleurs  experts  du 
domaine  conceme,  et  ce  sans  disposer  soi-meme  de 
I'expertise  correspondante.  Notons  au  passage  que,  la 
aussi,  le  logiciel  contient  un  savoir-faire  precieux  et 
permet  d'en  faire  beneficier  les  utilisateurs,  a  condition 
bien  sur  qu'ils  re^oivent  une  formation  adequate. 

Septicme  caractcristique  :  le  genie  logiciel  s'appuie  tres 
peu  sur  les  sciences  exactes,  non  par  ignorance  des 
ingenieurs,  mais  parce  que  les  niveaux  de  complexite 
atteints  couramment  depassent  largement  nos  capacites 
dans  le  domaine  de  la  logique.  Ma  vision  personnelle  est 
que  cela  ne  changera  pas.  II  ne  faut  done  pas  attendre 
d'outil  miracle  qui  resoudrait  nos  problemes  les  plus 
epineux. 

Huitieme  caractcristique :  le  moteur  du  progres 
technique,  notamment  augmentation  de  capacite  des 
machines,  standardisation  des  logiciels  de  base  et  des 
produits  divers,  perfectionnement  des  methodes.  le 
moteur  du  progres  technique,  disais-je.  est  surtout 
aujourd'hui  dans  le  secteur  civil. 

Neuvieme  caractcristique  fortement  liee  a  la  septieme 
et  a  la  huitieme  :  le  plus  difficile  n’est  pas  pour  nous  de 
faire  evoluer  la  technique  au  sens  strict,  car  nous 
trouvons  maintenant  beaucoup  d'outils  dans  le  secteur 
civil,  le  plus  difficile,  e'est  de  faire  evoluer  les  hommes, 
leur  mentalite,  leur  culture.  Les  vrais  problemes  que 
nous  rencontrons  dans  les  C3I  ne  sont  pas  du  domaine  de 
la  technique,  mais  de  celui  de  I'organisation.  Les 
s}^stemes  C3I  sont  de  plus  en  plus  complexes  et  de  plus 
en  plus  integres  dans  les  processus  de  decision  et  de 
commandement ;  leur  maitrise  requiert  une  e\'olution  des 
methodes  adaptee  a  celle  de  la  technologic  et  de  la 
complexite.  Une  mise  en  cause  profonde  des  methodes 
existantes  sera  probablement  indispensable,  ne  serait-ce 
que  par  la  necessite  de  formaliser  des  processus  de 
conception,  de  realisation  et  de  maintenance,  processus 
qui  auparavant  etaient  souvent  peu  formalises.  II  n'existe 
pas  de  methode  universelle  que  nous  pourrions  appliquer 
a  la  lettre  a  tous  les  cas  concrcts.  comme  I'illustrent  les 
demarches  de  "plans  qualite  (au  pluricl)"  repondant  a  un 
"manuel  qualite"  ou  de  "plans  dc  management  (toujours 
au  pluriel)"  repondant  a  une  "specification  de 
management" ;  pour  chaque  projet,  il  faut  particulariser 
la  methode  a  partir  des  principes  gencraux. 

2-  Cc.s  premisses  etant  posees,  regardons  maintenant, 
en  nous  appuyant  sur  les  invariants  (jiie  nous  venons 
d'identifier,  quelles  consequences  nous  pouvons  en 
tircr  pour  le  moycn  ct  le  long  terme. 


Tout  d'abord,  nous  pouvons  parier  presque  a  coup  sur 
que  la  taille  des  logiciels  des  C3I  continuera  a 
augmenter.  entrainant  la  croissance  correlative  de  leur 
complexite.  La  question  est  de  savoir  jusqu'ou  croitra 
cette  taille.  Comme  les  systemes  d’armes  sont  eux-memes 
de  plus  en  plus  complexes,  et  comme  les  C3I  leur  sont 
indispensables  et  participent  eux-memes  a  la  lutte  entre 
I'obus  et  la  cuirasse,  il  est  probable  que  la  plupart  de  ces 
C3I  vont  croitre  jusqu’a  la  taille  maximale  maitrisable, 
ce  qui  devrait  leur  donner  Tefficacite  maximale. 

Certains  diront  que,  si  Ton  a  du  mal  a  realiser  quelques 
gros  s>'stemes,  il  n’y  a  qu'a  en  reiser  beaucoup  de  petits. 
Cela  est  praticable  si  ces  petits  systemes  sont 
independants.  Un  ensemble  de  petits  systemes  fortement 
dependants  les  uns  des  autres  sera  beaucoup  plus  difficile 
a  coordonner  qu'un  grand  systeme  executant  les  memes 
fonctions.  et  presentera  de  plus  le  risque  que  chaque  petit 
S}  Sterne  tende  vers  la  taille  logicielle  maximale  et  qu'une 
partie  importante  du  logiciel  soit  consacree  a  la  gestion 
des  incoherences  inevitables  entre  developpements 
separes.  On  voit  done  que,  si  Ton  veut  limiter  la  taille 
globale.  et  done  le  cout  global,  on  a  interet  a  regrouper 
les  s>'stemes  fortement  correles. 

L'optimum  n'est  pas  aise  a  defmir.  et  sa  definition  n'est 
pas  aisee  a  objectiver,  mais  Ton  sent  la  un  ensemble  de 
forces  qui  poussent  a  retenir  de  gros  systemes  en  nombre 
relativement  restreint,  qui  auront  une  tendance  naturelle 
a  devenir  les  plus  gros  possible,  dans  les  limites  de 
I'efficacite.  Le  contour  de  ces  systemes  doit  etre  defini  en 
priorite  en  fonction  des  interactions  entre  les  fonctions 
concernees.  done  en  fonction  du  besoin  operationnel. 

Deuxieme  tendance  :  la  qualite  des  logiciels  au  sens 
large,  en  y  incluant  selon  un  usage  assez  repandu  les 
aspects  securite,  fiabilite,  flexibilite,  maintenabilite,  etc., 
cette  qualite,  done,  va  devenir  un  element  primordial  de 
tous  les  programmes  C3I  (et  de  beaucoup  d'autres 
egalement,  mais  la  n'est  pas  noire  propos),  En  effet, 
comme  nous  I'avons  vai,  le  logiciel  va  contenir  une 
quantite  de  savoir-faire  operationnel  de  plus  en  plus 
importante.  savoir-faire  qu'il  sera  de  plus  en  plus 
impraticable  de  regenerer  completement  lors  d'une 
renovation. 

On  peut  certes  arguer  que  I’industrie,  qui  realise  la 
plupart  des  systemes.  pourrait  s'arranger  seule  de  cet 
aspect  des  choses.  Cela  sera  insuffisant  pour  deux  raisons 
au  moins : 

-  premierement,  on  imagine  difficilement  que  la 
x’isibilite  sur  I'un  des  biens  les  plus  precieux  d'une 
organisation,  son  logiciel.  soit  entierement  deleguee  a 
I'industrie. 

-  deuxiemement,  la  qualite  sc  decline  en  un  certain 
nombre  de  crilercs  qui  ne  sont  pas  definissables  dans 
i’absolu.  mais  qu'il  faut  au  contraire  preciser  pour 
chaque  sxsteme,  ct  faire  vivre  comme  des  specifi¬ 
cations.  dont  ils  font  d'aillcurs  partie.  Cela  necessite 
une  participation  ctroilc  des  opcrationnels. 
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Troisieme  tendance :  les  composants  logiciels  vont  se 
generaliser  aussi  dans  le  domaine  C3L  Je  veux  dire  ici 
que  nous  aliens  voir  se  multiplier  des  outils  logiciels  du 
type  de  ceux  que  nous  trouvons  aujourd'hui  dans  ie 
commerce  civil,  mais  pour  des  fonctions  typiquement 
militaires.  Pour  illustrer  mon  propos,  je  citerai  pour  le 
civil  des  systemes  de  gestion  des  bases  de  donnees,  des 
gestionnaircs  d'ecrans,  des  tableurs,  des  traitements  de 
texte,  des  progiciels  de  comptabilite,  etc.  Dans  le 
domaine  des  C3I  AIR,  il  n'y  a  pas  grand  chose  a  citer 
aujourd'hui,  mais  la  technologie  existe,  mais  les 
materiels  et  logiciels  de  base  se  standardisent.  et  I'on  voit 
immediatement  I'interet  pour  I'interoperabilite  de  batir 
des  systemes  differents  a  partir  de  modules  communs. 
On  pent  imaginer,  par  exemple,  des  composants  logiciels 
pour  s'abonner  aux  liaisons  tactiques  normalisees,  pour 
gerer  des  donnees  geographiques,  pour  controler  des 
sv’stemes  d'armes,  pour  proposer  des  decisions,  pour 
formater  des  messages,  etc. 

Remarquons  egalement  que  e'est  un  excellent  moyen  de 
faire  baisser  la  complexite  d'ensemble. 

Cest  deja  comme  cela  que  precede  peu  ou  prou 
I'industrie  de  defense,  mais  chaque  societe  conseiv'e 
jalousement  I'exclusivite  de  ses  composants. 

Imaginons  une  situation  ou,  comme  cela  se  generalise 
dans  le  secteur  civil,  chacun  pourrait  beneficier  du 
meilleur  composant,  sur  lequel  la  loi  du  marche 
concentrerait  I'investissement :  il  est  clair  que  Tefficacite 
globale  en  serait  nettement  augmentee.  et  que  chacun  en 
tirerait  des  avantages  substantiels  a  condition  de  savoir 
se  creer  des  poles  d'excellence  et  de  savoir  les  conser\’er. 
Dans  un  domaine  dependant  fortement  de  Taction  et  de 
I'investissement  etatiques,  la  tendance  parait  ineluctable, 
et  il  vaut  mieux  s'y  preparer  le  plus  tot  possible. 

Dans  ce  que  je  viens  de  dire,  je  souligne  Timportance,  a 
mes  yeux,  de  "la  loi  du  marche".  Je  pense  que,  pour  des 
composants  utilisables  dans  de  multiples  s\'stemes.  il 
faudrait  se  garder  d'imposer  s>stematiquement  a 
I'industrie  des  bibliotheques  de  composants  standardises 
developpes  a  Teconomie  sous  Tautorite  de  TEtat.  avec 
notamment  un  seul  composant  par  function,  car  ie  risque 
de  decalage  par  rapport  a  Tenvironnement  international 
serait  trop  grand.  La  bonne  demarche  est  sans  douie  de 
rassembler  un  maximum  de  composants  dans  des 
bibliotheques  ou  des  catalogues  communs.  avec  acces  au 
marche  international,  et  de  laisscr  les  rcsponsablcs  de 
projets  faire  leur  meilleur  choix  en  fonciion  des 
e.xigences  qui  leur  sont  imposees.  Pour  les  composants 
utilises  dans  un  seul  systeme.  ou  dans  un  petit  nombre 
d'entre  eux,  Tunicitc  sera  par  contre  bcaucoup  plus 
frequente. 

Tout  cela,  bien  sur,  ne  sera  possible  que  grace  a  la 
poursuite  de  la  standardisation  des  archilcclurcs.  des 
logiciels  de  base  et  des  interfaces,  standardisation  a 


laqueile  les  composants  logiciels  contribueront 
egalement.  On  peut  d'ailleurs  anticiper  que,  dans  certains 
cas,  Tinterface  entre  applications  sera  formalisee  par  des 
composants  logiciels  communs  et  non  plus  par  des 
specifications  communes  au  sens  ou  nous  Tentendons 
aujourd'hui :  on  fera  ainsi  Teconomie  de  developpements 
multiples  pour  des  fonctions  voisines,  et  surtout  Ton 
diminera  les  tests  de  coherence  entre  logiciels 
developpes  a  partir  de  specifications  communes,  ainsi 
d'ailleurs  que  les  incoherences  residuelles,  qu'il  est 
pratiquement  impossible  d'eliminer, 

Trois  remarques  encore  avant  de  quitter  ce  sujet,  visant 
plus  particulierement  les  aspects  industriels  : 

-  tout  d'abord,  les  dispositifs  techniques  et  juridiques 
permettant  de  proteger  le  savoir-faire  sur  ce  type  de 
marche  existent, 

-  deuxiemement,  la  valeur  ajoutee  sur  la  vente  d’un 
systeme  concerne  en  majorite  les  developpements 
nouveaux  et  peu  la  vente  des  composants  logiciels.  Il 
n'y  a  done  pas  de  reel  manque  a  gagner  a  utiliser  des 
composants  developpes  par  un  autre. 

-  consideree  globalement,  I'industrie  a  interet  a  voir 
I'investissement  etatique  se  concentrer  sur  des 
developpements  innovants  plutot  que  sur  le 
financement  de  doublons  inutiles. 

Quatrieme  tendance  :  il  faudra  que  nous  ameliorions  a 
la  fois  la  rapidite  de  conception  des  C3I  et  la  rigueur  des 
realisations.  En  effet.  beaucoup  des  s>'stemes  actuels  se 
retrouvent  decales  par  rapport  au  besoin  lorsqu'ils  sont 
mis  en  service,  car  d'une  part  Ton  a  du  mal  a  bien 
formaliser  ce  que  Ton  attend  d'un  systeme  complexe 
futur  et.  d'autre  part,  il  est  parfois  difficile  de  prevoir  le 
besoin  longtemps  a  Tavance.  Le  phenomene  est  aggrave 
par  la  croissance  de  la  taille  des  s>'stemes  qui  tend  a 
rendre  les  modifications  plus  difficiles,  done  plus 
longues  a  mettre  en  oeuvre.  Des  outils  de  maquettage  de 
plus  en  plus  puissants  permettront  de  concevoir 
rapidement  de  nouvelles  fonctions  en  se  basant  sur  le 
systeme  reel  ou  sur  une  simulation  fine  de  celui-ci,  ce 
que  Ton  pourrait  appeler  "maquettage  evolutif.  Ces 
maquettes  pourront  dans  certains  cas  etre  utilisees 
operationneilement.  Mais  il  sera  imperatif  d'integrer  les 
fonctions  correspondantes  dans  un  processus  rigoureux 
de  realisation,  dans  le  cadre  d’une  ingenierie  de  systemes 
formalisee.  Cela  permettra  de  mieux  prevoir  le  besoin 
dctaillc  et  de  mieux  ie  preciser,  et  ce  le  plus  tard 
possible,  de  maniere  a  limiter  les  dccalages  precites  entre 
besoin  et  realisation.  Vouloir  faire  Teconomie  de  la 
rigueur  serait  a  terme  la  certitude  de  se  noyer  dans  la 
complexite  et  de  perdre  une  panic  importante  du  savoir- 
faire  contenu  dans  les  logiciels. 

Cinquiemc  tendance :  on  devrait  assister  a  un 
dcvcloppement  notable  des  cquipcs  d'officiers  de  haul 
niveau  specialisces  dans  la  conception  et  Tutilisation  des 
C3I.  en  y  incluanl  la  doctrine  et  Ics  procedures  d'cmploi. 
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Les  armees  de  I'air  ne  peuvent  se  desinteresser  des 
logiciels  qui  leur  sont  indispensables  et  qui  contiendront 
une  part  de  plus  en  plus  importante  de  leur  savoir-faire 
operationnel,  et  doivent  d'ailleurs,  avant  d‘en  arriver  la, 
consacrer  des  effectifs  significatifs  a  la  conception  de  ces 
logiciels.  L'eifort  d'abstraction  et  de  structuration 
necessaire  pour  concevoir  des  composants  perennes  doit 
debuter  dans  le  domaine  de  I'utilisation  operationnelle  et 
devra  s'y  referer  en  permanence. 

Sixieme  tendance  :  I'ingenierie  du  logiciel  deviendra  de 
plus  en  plus  une  science  a  part  entiere,  et  les  C3I 
devraient  y  jouer  un  role  particulierement  moteur. 

Science  a  part  entiere  ;  aujourd'hui,  on  a  trop  tendance  a 
considerer  que  I'ingenierie  du  logiciel  est  identique  a 
celle  des  autres  systemes,  ou  meme  qu'il  sufFit 
d'assembler  des  produits  existants  sans  formalisation  de 
I'ingenierie.  Cela  est  inadequat  pour  la  maitrise  des 
differentes  caracteristiques  que  nous  avons  observees 
jusqu'a  present.  Les  grands  systemes  informatiques  sont 
des  objets  particuliers,  auxquels  la  methode  scientifique 
doit  aussi  etre  appliquee,  et  ce  d'autant  plus  qu'ils  sont 
particulierement  difficiles  a  formaliser. 

Role  moteur  des  C3I :  que  Ton  me  permette  ici  d'etre  un 
peu  chauvin,  Les  informations  manipulees  par  les 
militaires  sont  beaucoup  plus  nombreuses  et  plus 
complexes  que  celles  qui  son  manipulees  par  les  civils,  et 
ces  informations  se  situent  dans  des  environnements 
potentiellement  beaucoup  plus  hostiles,  avec  des  ddais 
de  reaction  beaucoup  plus  courts  et  en  interoperabilite 
beaucoup  plus  etroite  avec  des  partenaires  beaucoup  plus 
nombreux.  Un  grand  SIC,  c'est  un  peu  comme  si  Ton 
integrait  dans  une  entreprise  les  systemes  de  gestion  des 
stocks,  de  comptabilite  generate,  de  comptabilite 
analytique.  d'ateliers  automatiques,  d'information  sur  la 
concurrence,  etc.,  le  tout  en  temps  reel  et  en 
interoperabilite  totale  avec  les  fournisseurs.  les  clients  et 
les  banquiers.  On  en  est  encore  tres  loin,  et  c’est  sans 
doute  Tune  des  raisons  pour  lesquelles  les  outils  et 
methodes  du  secteur  civil  dit  "de  la  gestion"  sont  assez 
peu  appliques  a  nos  C3I.  II  y  a  certainement  des  progres 
a  faire  en  s'en  inspirant  plus,  mais  cela  ne  sulfira  pas 
pour  satisfaire  I'ensemble  du  besoin.  Les  C3I  devront  se 
preoccuper  eux-niemes  de  Tapplication  du  savoir-faire 
existant  a  leur  domaine,  et  devront  pour  cela  y  apporter 
des  ameliorations  significatives. 

Scptiemc  tendance :  les  organisations  de  comman- 
dement  deviennent  de  plus  en  plus  evolutives,  d'ou  il 
decoule  deux  consequences  : 


-  les  systemes  doivent  etre  tres  flexibles  ;  la  structure  de 
commandement  peut  evoluer  rapidement,  mais  les 
functions  restent  de  par  leur  nature  relativement 
stables, 

-  il  est  en  consequence  indispensable  que  les  systemes 
C3I  soient  con^us  a  partir  de  leurs  aspects  fonctionnels 
et  non  a  partir  des  structures  des  commandements  ou 
des  centres  d'operations. 

Par  exemple,  les  functions  AIR  doivent  former  un  tout 
coherent  parce  que,  comme  le  General  Douin  nous  I'a 
rappele,  la  bataille  aerienne  est  et  restera  unique  sur  un 
theatre  d'operations  donne. 

♦♦♦ 

Il  serait  hasardeux  d'aller  plus  avant  aujourd'hui  dans 
cette  vision  du  futur.  J'espere  que  certains  font  trouvee 
un  peu  depassee  et  que  d'autres  font  trouvee  plutot 
ideale,  car  cela  prouverait  qu'elle  aurait  atteint  le  juste 
compromis  permettant  de  susciter  la  reflexion,  sans 
pretendre  a  I’exactitude,  qui  n'existe  pas  a  si  long  terme. 
Et  c'est  justement  de  compromis  qu'il  s'agit  dans  notre 
demarche  d'amelioration  permanente  de  maitrise  des 
C3I :  compromis  entre  rigueur  et  rapidite,  compromis 
entre  formalisme  et  empirisme,  compromis  entre 
concurrence  et  cooperation,  compromis  entre  etatique  et 
industriel,  et  nous  pourrions  allonger  a  volonte  la  liste 
des  compromis  a  faire  evoluer  entre  les  diverses  forces  en 
presence.  Dans  ce  mouvement,  qui  est  celui  de  tous  les 
grands  s>'stemes  informatiques,  les  C3I  devraient  jouer 
un  role  moteur.  ce  que  reflete  particulierement 
I'organisation  specifique  mise  en  place  sous  I'egide  de 
I'Etat-major  des  armees  et  de  la  Direction  de 
I’electronique  et  de  I'informatique  de  la  DGA. 

Dans  ce  contexte,  les  C3I  AIR,  et  notamment  le  SCCOA, 
devraient  se  placer  particulierement  en  pointe,  car  c'est 
dans  notre  secteur  que  le  besoin  de  coherence  a  grande 
echelle  est  le  plus  fort,  ce  qui  explique  d'ailleurs  la 
creation  du  programme  SCCOA.  Les  operations 
aeriennes  sont  conduites  a  partir  d'organismes 
centralises,  dans  un  espace  aerien  unique,  a  partir  de 
bases  qui  doivent  etre  capables  d'accueillir  tous  les  types 
d'avions.  avec  des  delais  de  reaction  extremement  courts 
et  cn  interoperabilite  permanente  avec  nos  allies. 

Soyons  ambitieux  et  esperons  que  les  progres  necessaires 
pour  la  maitrise  de  ces  s>stemes  complexes  nous 
rendront.  au  moins  particllcment.  le  leadership  que  nous 
avons  perdu  au  profit  du  secteur  civil. 
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L  THE  ARCHITECTURE  ISSUE 

Architecture:  a  word  that  is  used  in  more  and  more  areas 

and  namely  in  the  C3I  world.  What  is  an  architecture, 

who  is  the  architect  and  what  is  his  business,  what  are 

the  relationships  with  the  other  players,  what  are  his 

tools  and  how  does  he  work?  This  is  the  purpose  of  this 

briefing. 

An  architecture  concept  applies  to  a  system,  the 
complexity  of  which  is  more  than  simply  the  addition  or 
the  connexion  of  subsystems.  This  is  the  way  large  C3I 
systems  for  Air  Defense  and  Air  Operations  can  be 
designed,  since  they  are  federating  a  large  set  of 
planning,  tasking,  mission  preparation,  mission  control, 
intelligence,  communications  that  are  overlapping  in  a 
complex  set  of  System  of  Systems. 

This  intrication  of  the  missions  and  functions  in  a 
Combined,  Joint  environment  has  generated  the  need  for 
a  separation  between  organic  and  operational  functions: 
in  France,  a  single  operational  command,  the  CDAOA 
(Air  Defense  and  Air  Operations  Command)  has 
authority  and  responsibility  for  the  organization, 
command  and  control  of  any  mission  of  the  French  Air 
Force,  let  it  be  defensive,  offensive  or  support,  either  in  a 
national  environment,  or  in  coordination  with  the  Allies. 

Combined  joint  operations  have  push  to  more 
coordinated  C3I  s}'stems:  the  NATO  ACCS  and  the 
french  SCCOA  (Systeme  de  Commandement  el  de 
Conduite  des  Operations  Aeriennes)  are  the  most 
obvious  exaiiiples.  Furthermore,  the  top-down 
requirements  for  a  comprehensive  Command  and 
Control  system  is  complemented  by  the  bottom-up 
pressure  from  technology:  Commercial  off-the-shelf 
products,  national  standards  and  procedures,  worldwide 
integration  of  communication  systems  make  a 
coordination  necessary  at  s>'stem  of  s)'stems  level.  That  is 
the  work  of  an  Architect. 


2,  THE  SCCOA  ENVIRONMENT 
The  SCCOA  environment  demonstrates  how  complex 
the  interfaces  are;  and  the  interfaces  do  not  only  transfer 
data  and  bytes:  they  have  to  be  described  first  as  common 
doctrines  and  procedures  betAveen  neighboring  systems. 

-  As  far  as  ACCS  is  concerned,  the  interface  with 
SCCOA  is  more  than  a  border:  both  systems  arc 
developed  in  parallel,  according  to  similar  standards, 
and  according  to  a  similar  functional  breakdown:  an 


ACCS  Command  and  Control  Center,  the  CARS  in 
Lyon-Montverdun,  will  be  implemented  in  France. 

-  As  far  as  Air  Traffic  Control  and  Air  Traffic 
Management  is  concerned,  the  regulations  and 
procedures  must  be  shared  and  coordinated  between 
the  cKdlian  and  the  military.  In  France,  the  military  air 
traffic  management  is  fully  independent  from  the 
civilian,  and  the  sharing  of  responsibilities  is  vaiying 
according  to  peace,  crisis  and  war  situation. 

-  Joint  operations  require  coordination  and  integration. 
An  example  is  the  development  of  a  Joint  mission 
preparation  system  for  the  Air  Force  and  for  the 
aircraft  carriers  and  the  airbases  of  the  French  Na\y 
Aviation. 

-  At  Joint  Chief  of  Staff  level,  the  frame  of  national 
intelligence  (the  DRM  for  Direction  du  Renseignement 
Militaire)  must  be  coordinated  with  the  Air 
Intelligence,  which  produces  intelligence  data  from  the 
Air  Force  sensors,  and  which  processes  and  uses 
intelligence  data  for  the  Air  Operations. 

All  these  relations  and  interfaces  have  to  be  organized 

and  managed.  This  is  not  a  self  generated  process. 


3.  THE  NEW  FUNCTIONS  IN  SCCOA 

SCCOA  develops  and  implements  new  concepts  within 

the  Air  Force  structure: 

-  the  Air  Command  and  Control  process  is  suited  to  the 
new  Air  Force  organization  that  was  implemented  in 
June,  1994:  a  single  operational  Command  is  in  charge 
of  defensive,  offensive  and  support  operations;  it  relies 
on  the  main  national  Command  Center  for  Air 
Operations  (CCOA)  in  Tavemy  near  Paris.  The 
common  ACCS/SCCOA  center  of  LAun-Montverdun 
will  later  be  closely  integrated  in  the  planning  tasking 
and  mission  control  process. 

-  a  mobile,  air  transportable  Command  and  Control 
S}'Stem  (the  C3M)  will  be  developed  for  overseas 
operations.  It  will  perform  the  planning  and  tasking 
functions,  and  the  air  mission  control  and  air  traffic 
control  as  well. 

-  new'  communication  networks  will  integrate  Link  16, 

-  finally,  the  air  operations  will  be  organized  as  an 
Extended  Air  Defense  concept,  as  defined  in  the  White 
Paper  on  defense  released  in  spring  1994. 

SCCOA  is  in  charge  of  the  development  and  integration 
of  these  new  functions  along  with  the  c\’olution  of  the 
former  systems,  namely  STRIDA. 


Paper  presented  at  the  AGARD  MSP  3rd  Symposium  on  ‘'Tactical  Aerospace  01  in  Coming  Years'*, 
held  in  Lisbon,  Portugal  from  15th  May  to  18th  May  1995,  and  published  in  CP-557, 
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4.  ARCHITECT  AND  PRIME  CONTRACTORS 
The  spectrum  and  the  complexity  of  a  such  system  as 
SCCOA  requires  a  System  Engineering  organization.  As 
far  as  C3I  systems  are  concerned,  system  engineering 
supports  both  operational  and  technical  functions, 
along  with  tools  and  methods  for  the  management  of  a 
very  large  programme.  Stand-alone  systems  drive  more 
or  less  a  single  prime  contractor  structure.  Large, 
distributed  C3I  systems  are  rather  a  federation  of 
subsystems  that  must  work  all  together  in  a  smooth  and 
flexible  way. 

In  the  USA,  the  word  "Architect"  is  more  or  less 
equivalent  to  a  "System  Engineering  and  Integration" 
(SEI)  contract.  It  goes  along  with  a  software  and 
hardware  exclusion  clause  to  prevent  any  conflict  of 
interest  between  the  SEI  organization  and  the  contractors 
of  the  subsets  of  the  system. 

Due  to  the  design  and  overall  structure  of  SCCOA,  this 
SEI  activity  looks  rather  like  a  System  of  Systems 
Engineering  (SSE)  contract. 


5.  THE  PLAYERS 

Starting  from  the  well  known  V-like  process  for  the 
development  of  a  s}'stem,  we  can  define  three  main 
players: 

-  the  Air  Force,  in  charge  of  the  statement  of  the 
operational  requirements,  at  the  upper  left  of  the 
process, 

-  the  Architect,  on  behalf  of  the  Government  Agency 
(DCAe/STTE)  in  charge  of  the  s\'stem  management 
and  system  engineering,  in  the  central  part  of  the  V. 
The  main  output  of  the  Architect  are  the  general 
specifications,  at  System  and  Subs>'stem  levels.  These 
specifications  are  the  input  for  the  subs>'stem 
developers. 

-  the  subs\'stem  developers,  at  the  bottom  of  the  V.  They 
develop  hard\\'are  and  software  according  to  the 
general  specifications  derived  b\^  the  Architect.  They 
get  their  development  contracts  from  the  Government 
Agency'  (STTE),  not  from  the  Architect.  Therefore, 
their  is  no  overall  prime  contractor  in  the  process. 

After  completion  of  the  development,  the  subs}'stems 
acceptance  tests  are  performed;  then,  a  validation  at 
system  level  is  carried  out  in  a  System  Test  Bed  (the 
Centre  de  Definition,  Experimentation  et  Validation  du 
SCCOA,  or  CDEVS)  located  on  the  Air  Force  Test  Base 
of  Mont  de  Marsan.  The  equipments  are  assembled  and 
integrated  in  a  S}'Stem  level  configuration,  linked  to  real 
world  s)'stems  like  radars,  AWACS,  SAMS,  CRCS,  etc., 
and  check-out  of  overall  s>'stem  performance  is  carried 
out. 

In  this  process,  the  Architect  is  in  charge  of  the 
consistency  of  the  full  s>'stcm,  industry'  contractors  being 
in  charge  of  the  development  of  the  elements. 


6.  THE  SYSTEM  BREAKDOWN 

The  system  breakdown  derives  from  two  processes: 

“  the  operational  requirements  statement  from  the  Air 
Force,  though  a  long  and  tedious  functional  analysis 
process, 

-  the  development  of  a  functional  architecture  that 
translates  the  operational  structure  into  building  blocks 
and  helps  deriving  the  data  flows  and  processing  power 
required. 

SCCOA  is  built  around  the  same  functional  architecture 
as  the  ACCS,  though  the  physical  implementation  may 
be  very'  different  due  to  the  specific  organization  of  the 
french  Air  Force.  Besides,  the  spectrum  of  SCCOA  is 
larger  than  the  ACCS,  since  SCCOA  encompasses  more 
functions  (especially  Intelligence  and  higher  level 
Commands  that  are  embedded  in  the  ACE-ACCIS  or 
BICES  programmes  in  the  NATO  structure). 

The  physical  architecture  is  based  upon  equipments 
implemented  in  various  centers:  for  example,  the 
equipments  dedicated  to  Force  Management  are  scattered 
in  the  CCOA,  the  Wing  Operation  Centers,  the 
Squadron  Operation  Centers,  etc. 

7.  SYSTEM  MANAGEMENT 

SCCOA  has  demonstrated  that  large  C3I  systems  must 
stress  some  key  management  issues: 

-  the  derivation  of  the  military  requirements, 

-  the  need  for  a  common  sy'stem  engineering  acii\'ii}’ 
bct^^■een  the  Air  Force  (the  user),  the  Government 
Agency  (responsible  for  the  development)  and  the 
industry'  (Architect  and  contractors).  C3I  sy'stems  need 
an  iterative  and  flexible  roadmap  because  of: 

-  the  man-in-the-loop  who  influences  the  derivation  of 
the  requirements,  compared  to  more  automated 
sy'Stems, 

-  the  rapid  evolution  of  the  hardware  and  software 
products  and  namely  the  COTS  (Commercial-off-the- 
shelO  that  make  obsolete  rigid,  stiff  s>’stems 
compared  to  layered,  flexible,  open  designs. 

Rapid  prototyping,  demonstration/validation  labs  are 
keys  to  the  implementation  of  systems  that  the  user  may 
play  with  very'  early,  and  can  make  evolve  as  soon  and  as 
frequently  as  he  needs. 

The  Test  Bed,  at  system  level,  is  the  place  w'herc 
ultimate  validation  and  doctrine  or  procedure  evolution 
may  be  controlled. 

8.  THE  ARCHITECT  TOOLS 

The  Architect  relies  on  several  tools  to  perform  system 
management  and  system  engineering: 
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-  the  management  specification  is  the  common  law  of 
the  players.  It  defines  the  management  principles,  the 
breakdown  organization,  the  relationship  and 
responsibility  of  the  players.  It  is  written  so  as  to  allow 
the  contractors  to  respond  to  the  requirements 
according  to  their  own  culture  and  to  their  general 
tools,  provided  they  are  compliant  with  the  overall 
requirements. 

-  the  System  Studies  encompass  top-down  analysis 
(architecture  analysis,  input/oulput  and  interface 
requirements,  flow  analysis,  etc.)  and  cross-system 
requirements  (safety,  reliability,  LSI,  etc.).  They  assess 
the  system  consistency  and  the  system  breakdown. 

-  the  System  Planning  and  System  guidelines  is  a 
schedule,  a  budget  plan  and  a  consistency  matrix 
between  subs>'stems.  It  runs  over  a  12  years  time  frame. 

-  the  System  Test  Bed  (CDEVS). 


CONCLUSION 

SCCOA  is  a  major  programme,  part  of  the  french 
Military'  Programmes  Law.  It  develops  and  federates 
numerous  systems  that  support  the  new  organization  of 
the  French  Air  Force,  based  upon  a  single  Operational 
Command. 

The  development  is  structured  according  to  phases,  each 
of  them  running  over  a  few  years,  and  overlapping:  each 
phase  develops  new  elements,  and  prepares  for  the 
development  of  future  ones  in  the  next  phase. 

This  process  is  made  mandatory'  because  the  evolution  of 
the  operational  requirements  and  of  the  tcchnolog}'  is  not 
predictable  over  a  very'  long  period.  Therefore,  a  flexible 
organization  has  to  be  set  up,  but  the  more  flexible  it  is, 
the  more  coordination  it  requires.  Defining  long  term 
planning,  smoothing  the  budget,  making  consistent  the 
requirements,  mixing  existing  systems  and  brand  new 
ones,  making  possible  combined  joint  operations  is  the 
mission  of  the  System  Architect,  on  behalf  of  the  Air 
Force  and  of  the  DGA,  with  the  support  of  the  industry- 
contractors. 
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1.  SUMMARY 

A  technical  management  structure  using  Model-Based 
Systems  Engineering  (MBSE)  concepts  and  implemented 
via  an  integrated  suite  of  tools  is  recommended  to  manage 
the  evolution  of  tactical  aerospace  C^I  systems.  A 
system-of-sy stems  (S2)  engineering  perspective  is 
advocated  to  identify  processes,  methods,  and  tools  that 
support  the  capture,  analysis,  and  management  of  these 
systems.  An  integrated  systems  engineering 
environment  (ISEE)  is  introduced  as  the  mechanism  used 
to  capture,  store,  and  generate  the  information  necessary 
to  manage  change  across  tactical  aerospace  C^I  systems. 

Work  currently  being  performed  to  manage  change  of  the 
Air  Warning  Mission  C^I  systems  within  the  Integrated 
Tactical  Waming/Attack  Assessment  (Integrated  TW/AA) 
S2  is  discussed  to  show  how  MBSE  concepts  are  currently 
being  used.  Extensions  of  this  work  are  presented  in 
terms  of  an  evolving  tactical  aerospace  C^I  systems 
architecture  and  the  inclusion  of  other  tools.  Finally, 
advances  in  enabling  technologies,  methods,  and  tools 
are  mentioned  to  suggest  directions  of  how  to  fully 
develop  a  tactical  aerospace  C^I  systems  ISEE. 

2.  INTRODUCTION 

Lifecycle  change  management  of  the  multinational 
tactical  aerospace  C^I  S2  is  a  complex  engineering 
management  effort  that  is  expected  to  continue.  In  [1],  a 
proposed  architecture  for  future  tactical  air  operations  C^I 
is  discussed.  The  complexities  of  understanding  the 
behavior  of  such  an  architecture,  along  with  the 
migration  of  today’s  primarily  “stovepiped”  systems  to 
achieve  an  interoperable  architecture,  are  considered  a 
major  technical  and  management  challenge.  The 
disciplined  approach  of  MBSE,  when  coupled  with  an 
ISEE  comprised  of  commercial-off-the-shelf  (COTS) 
tools,  appears  to  be  a  promising  systems  engineering 
(SE)  approach  to  help  manage  such  an  evolution. 

2.1  Model-Based  Systems  Engineering 
In  [2,  3],  MBSE  is  described  as  the  discipline  required  of  SE 
to  design  and  build  a  real  system  based  on  a  thorough  and 
rigorous  understanding  of  all  requirements.  Such  an 
imderstanding  is  necessary  to  create  a  model  that  will  yield 
the  design  of  the  system.  From  this  design,  a  real  system 
can  then  be  built  that  will  satisfy  all  of  its  requirements. 
This  formal  approach  to  SE,  one  built  upon  the  use  of 
models  to  design  the  system,  is  extended  here  and  applied 
throughout  a  system’s  lifecycle.  These  MBSE  tenets  are 
subscribed  to  here  to  investigate  how  models  built  using 
COTS  tools  can  support  the  lifecycle  changes  of  the 


tactical  aerospace  C^I  S2.  The  lifecycle  phases,  as 
described  within  MBSE,  are: 

1.  Requirements  development 

2.  Concept  development 

3.  Full-scale  engineering  development 

4.  System  development 

5.  System  test  and  integration 

6.  System  operation 

7.  System  retirement 

Change  management  of  the  tactical  aerospace  C^I  S2  is 
concerned  with  each  lifecycle  phase  of  all  systems,  along 
with  that  of  the  integrated  S2.  Hence,  the  view  taken  is 
one  of  managing  the  evolution  of  the  S2  through 
knowledge  of  each  C^I  system  and  its  end-to-end  behavior. 
In  addition,  different  architectural  configurations  demand 
that  change  management  be  supported  via  differing  views 
of  the  design.  That  is,  the  design  capture  and  display 
methods  must  be  sufficiently  robust  to  support  multiple 
views  of  the  S2  [4].  This  allows  engineers  and  managers 
to  view,  analyze,  assess,  and  document  the  evolution  of 
the  S2  from  the  most  useful  perspective  that  meets  their 
needs. 

Figure  1  shows  a  simple  MBSE  “process”  engine  that 
depicts  the  major  steps  that  must  be  performed  in  each 
phase  of  the  lifecycle  [5].  Each  step  represents  a  set  of 
tasks  that  is  tailored  to  meet  the  specific  goals  within  each 
lifecycle  phase.  In  addition,  this  iterative  process  is 
applicable  at  any  level  of  detail  within  each  phase.  Hence, 
this  tailorable  and  iterative  model  can  be  repeatedly 
applied  across  the  seven  lifecycle  phases,  as  well  as 
throughout  each  layer  of  detail.  Models  constructed  in  one 
phase  will  evolve  as  the  system  progresses  through  its 
lifecycle. 

The  Behavior  Model  in  Figure  1  refers  to  “what  the  system 
or  S2  does,"  while  the  Object  Model  captures  “how  the 
system  or  S2  is  implemented."  Here,  “object”  refers  to  real- 
world  objects  (e.g.,  bioware,  hardware,  and  software).  Under 
Trade-Off  Analysis,  issues  involving  performance  vs.  cost, 
programmatics  vs.  cost,  technology  vs.  risk,  etc.,  are 
examined.  Once  a  feasible  solution  is  achieved,  the  Build- 
and-Test  Plan  based  on  the  models  is  then  created. 

The  use  of  models  to  design  systems  and  control  system 
change  differs  from  today’s  predominant  approach  of  using 
documents  to  drive  the  design.  Although  documentation  is 
extremely  important  and  useful,  document-driven  design 
and  its  subsequent  use  to  manage  the  evolution  of  a  system 
has  often  proven  itself  inadequate.  Such  inadequacies  stem 
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Iterate  to  Find  Feasible  Solution 


Figure  1.  Model-Based  Systems  Engineering  “Process” 


from  such  things  as  the  informality  and  inexactness  of  the 
written  language  and  the  inability  to  maintain  the 
voluminous  documentation  required  by  today’s  acquisition 
processes  [6].  MBSE  offers  a  formal  approach  that»  when 
coupled  with  an  ISEE,  permits  the  generation  of 
documentation  in  any  desired  format. 

The  overall  goal  is  to  satisfy  all  requirements  via  models. 
The  model-captured  information  is  then  used  to  provide 
customized  documents  that  address  specific  customer 
needs  and/or  technical  and  management  issues.  This 
approach  is  used  in  [7,  8],  where  COTS  tools  are  used  to 
capture  C^I  S2  architectures,  as  well  as  to  produce 
useful  documents. 

To  be  successful  in  the  design  and  evolution  of 
complex  S2,  MBSE  requires  an  implementation  vehicle 
beyond  paper  and  pencil.  The  emergence  of  COTS  SE 
tools,  the  existence  of  several  domain-specific  COTS 
tools,  and  the  ^pearance  of  standards-based  COTS 
products  that  provide  the  underlying  technology,  all 
contribute  to  the  realization  of  an  implementable 
MBSE  approach.  The  next  section  discusses  the 
expanded  role  of  tools  in  the  21st  century  as  they 
apply  to  the  tactical  aerospace  C^I  S2  arena. 

2.2  Expected  Roles  of  SE  Tools 
SE  tools  are  expected  to  support  the  entire  lifecycle  of 
a  system,  expanding  their  focus  to  include  the  entire 
design  capture  process  [4].  The  following  lists  some 
of  the  more  important  types  of  information  that  are 
expected  to  be  captured  by  tools-develop>ed  models 
within  each  phase  of  the  lifecycle: 

1 .  Requirements  Development 

-  External  environment  context 


-  “What  if?”  scenarios  (new  threats, 
missions,  technology,  etc.) 

-  End  user  requirements  traceability 

-  Risk  assessment 

-  Effectiveness  measures 

2.-4.  Concept  Development,  Full-Scale  Engineering 
Development,  System  Development 

-  System  architecture  (functional,  physical, 
operational  views) 

-  Architecture  mapping  to  requirements, 
effectiveness  measures 

-  Specification  generation 

-  History  of  decision  making,  rationale,  trade¬ 
offs 

-  Design  strategies,  implementations 

-  Interface  definitions 

-  Capture  of  data  items  and  messages  across 
intemal/extemal  interfaces 

-  Information  on  standards,  protocols,  and 
products 

-  Traceability  to  requirements  and 
documentation 

-  Interoperability  and  integration  analyses 

5 .  System  Test  and  Integration 

-  Traceability  at  all  levels  to  objects, 
requirements,  system  effectiveness 
measures,  and  documentation 

-  Test  plans  and  procedures,  exit  criteria 

-  Historical  record  of  results,  problems, 
outstanding  issues,  modifications,  etc. 

6.  System  Operation 

-  Record  of  “what  if?”  exploration  analyses 
and  upgrades 
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-  Cost  and  re-engineering  data 

-  Requirements  changes 

-  Extemal/intemal  drivers,  resulting 
changes,  and  data  on  the  decision  process 

-  COTS  product  migrations 

7.  System  Retirement 

-  Environmental  considerations 

-  Disposal  facilities  information 

Achieving  these  expectations  for  systems  of  the  scale 
of  the  tactical  aerospace  C^I  S2  requires  a  set  of  large, 
complex  models.  The  capability  of  tools  to  scale  up  to 
address  such  a  class  of  problems  has  not  yet  been 
demonstrated.  However,  large  C^I  S2  architecture 
models  have  been  built  that  support  the  change 
management  process  [7,  8].  The  Air  Warning  Mission 
end-to-end  model  discussed  in  Section  5  is  such  an 
example. 

Scoping  the  size  of  the  models  required  to  manage 
change  within  the  tactical  aerospace  C^I  S2  is  strongly 
dependent  on  the  set  of  questions  to  be  answered. 
Clearly,  no  single  model  (or  tool)  or  set  of  models  (or 
suite  of  tools)  can  be  expected  to  address  all  of  the 
topics  mentioned  above.  However,  by  understanding 
the  types  of  questions  to  be  addressed,  an  Information 
Model  (IM)  can  be  created  to  understand  the  scope  and 
level  of  detail  of  the  information  captured  by  the 
model(s).  The  next  section  discusses  some  represen¬ 
tative  questions  related  to  change  management  at  the 
S2  level,  as  well  as  at  the  systems  level. 

3.  CHANGE  MANAGEMENT  QUESTIONS 
The  goal  of  the  MBSE  approach  is  to  provide 
information  in  useful  forms  that  support  NATO 
decision  makers  in  addressing  "what  if?"  questions  that 
will  dictate  the  evolution  of  the  tactical  aerospace  C^I 
S2.  Decision  makers,  program  managers,  and  warriors 
must  address  questions  that  include: 

•  What  are  the  effects  of  policy  changes  on  my 
missions,  requirements,  systems,  and  their 
operational  effectiveness? 

•  What  are  the  capabilities  of  existing  assets, 
including  duplication,  constraints,  and  shortfalls? 

•  For  given  scenarios,  what  are  the  expected 
outcomes  under  various  deployments,  using 
different  asset  suites? 

•  What  are  the  measures  of  success  and  how  do  assets 
(systems,  models  and  simulations  [M&S],  bioware) 
support  these  measures? 

•  What  happens  if/when  certain  systems  are  retired? 

•  Should  existing  systems  be  modernized  or  must  new 
systems  be  acquired? 

•  What  is  the  current  status  (baseline)  of  tactical 
aerospace  C^I,  what  is  being  acquired  or 


modernized,  what  requirements  are  being  met,  and 
what  are  their  shortfalls? 

•  What  assets  (C^I  systems,  M&S,  organizations, 
agencies,  contractors)  are  best  suited  to  perform 
certain  missions,  studies,  or  analyses  (i.e.,  how  to 
apply  the  right  assets  to  the  right  job)? 

Within  the  tactical  aerospace  C^I  S2,  existing  systems 
are  periodically  upgraded,  with  new  systems  contin¬ 
ually  integrated  into  the  operational  S2.  An  effective 
C^I  capability  can  only  be  sustained  if  impacts  across 
the  S2  are  understood  well  in  advance  of  implemen¬ 
tation.  Since  these  NATO  assets  are  imder  the  control 
of  multiple  organizations,  the  challenges  faced  in 
maintaining  an  effective  C^I  capability  are  even 
greater  than  with  a  S2  maintained  by  a  single 
organization. 

Integration  across  multiple  systems  needs  to  be 
accomplished  from  several  SE  aspects.  For  example, 
software  developers  and  maintainers  focus  on  de¬ 
signing  and  testing  software  for  individual  systems. 

A  cross-system  integration  focus  is  needed  to  ensure 
that  the  individual  development  and  maintenance 
releases  gracefully  integrate  into  the  operational  S2. 
Key  aspects  to  address  in  controlling  the  tactical 
aerospace  C^I  S2  evolution  involve  system-wide 
change  management,  configuration  control,  and 
identification  of  modernization  needs  and 
opportunities. 

To  accomplish  integrated  change  management,  several 
questions  need  to  be  addressed  to  ensure  that  require¬ 
ments  and  changes  are  designed  and  consistently 
implemented  across  systems.  At  an  engineering  level, 
such  questions  include: 

•  What  are  the  existing  and  target  architecture 
baselines? 

•  What  systems  and  software  are  affected  by  changes? 

•  What  are  the  cost,  schedule,  and  performance  impacts 
of  changes? 

•  What  integration  and  testing  coordination  is  required 
for  cross-system  changes? 

Key  questions  to  address  in  system-wide  configuration 
control  include: 

•  How  to  track  software,  hardware,  and  document 
changes  across  systems. 

•  How  to  keep  design  and  testing  schedules 
synchronized. 

Perhaps  the  most  difficult  aspect  to  address  in 
controlling  S2  evolution  is  where  to  spend  limited  funds 
for  re-engineering  or  upgrading  of  legacy  systems. 

Since  software  plays  a  determining  role  in  the  overall 
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cost  of  a  C^I  system,  understanding  the  evolution  of 
software  modifications  is  a  key  factor.  Questions  to 
address  in  determining  best  return  on  investment  related 
to  improving  tactical  aerospace  C^I  flexibility  and 
lifecycle  costs  include: 

•  Which  software  is  being  changed  repeatedly? 

•  Which  software  changes  are  the  most  expensive? 

The  issues  described  above  must  be  addressed  from  a  S2 
viewpoint  to  avoid  local  changes  to  individual  systems 
that  unknowingly  have  negative  impacts  on  other 
systems. 

The  importance  of  precisely  understanding  what  kinds  of 
questions  a  model  (or  set  of  models)  is  supposed  to  help 
answer  cannot  be  overemphasized.  Once  the  questions 
to  be  answered  are  understood,  the  scope  of  the  model(s) 
can  be  determined  via  an  IM.  The  next  section  discusses 
some  of  the  key  aspects  of  an  IM. 

4  .  INFORMATION  MODELS 
An  IM  is  used  to  define  the  contents  of  a  model,  or 
models,  as  well  as  to  add  structure  to  the  model’s  design. 
Several  schemes  can  define  an  IM,  including  an  entity- 
relationship-attribute  model  or  an  object-oriented 
model,  which  may  be  based  on  any  number  of  notations 
[9].  The  IM  shown  in  Figure  2  can  be  considered  a 
“basic  IM”  in  that  the  classes  of  all  objects  to  be 
modeled  are  shown.  To  apply  this  IM  within  each  phase 
of  the  lifecycle  and  to  each  task  in  the  process  shown  in 
Figure  1  requires  a  decomposition  of  both  the  process 
tasks  and  the  IM.  Examples  of  such  decompositions  can 
be  found  in  [9].  Such  decompositions  describe  the  scope 
and  content  of  each  model  for  each  task  within  a 
lifecycle  phase.  The  commonalities  and  differences  in 
the  decomposed  object  classes  help  identify  interfaces 
across  models  that  support  different  lifecycle  phases. 
Without  the  complexities  that  differing  tool  semantics 


add  and  the  configuration  management  challenges 
associated  with  such  models,  the  IM  is  an  excellent 
vehicle  for  the  construction  of  complex  models. 

Figure  2  shows  a  basic  IM  used  to  support  traceability 
among  architecture  elements.  This  IM  has  been  used  to 
develop  large  S2  architecture  models  [7]  that  address 
many  of  the  issues  discussed  in  lifecycle  phases  2 
through  4  in  Section  2.2.  Note  that  this  IM  is 
sufficiently  robust  to  allow  functional,  physical,  and 
operational  views  of  the  architecture,  thus  supporting 
the  construction  of  both  behavioral  and  object  models. 
Each  object  in  the  IM  can  further  be  decomposed  into 
subclasses,  which  adds  further  structure  and  constraints 
on  the  scope  and  content  of  the  models.  Some  examples 
can  be  found  in  [9]. 

The  following  section  discusses  how  the  principles 
described  above,  along  with  the  IM  in  Figure  2,  were 
applied  to  develop  the  Air  Warning  Mission  S2 
architecture  model.  Extensions  to  the  traceability  IM  to 
permit  control  of  this  S2  are  discussed  as  an  example  of 
how  such  a  model  can  be  constructed  for  the  tactical 
aerospace  C^I  S2. 

5  .  AIR  WARNING  MISSION  MODEL 
5.1  Use  of  RDD-100 

The  Air  Warning  Mission  architecture  is  modeled  using 
the  COTS  SE  tool.  Requirements  Driven  Development, 
RDD-100.  (RDD-100  is  a  registered  trademark  of  Ascent 
Logic  Corporation.)  The  RDD-100  model  captures  the 
functional,  physical,  and  operational  views  of  the  S2 
architecture  in  a  single  data  store.  Information  is 
extracted  via  customized  reports  that  assist  systems 
engineers  in  identifying  cross-system  impacts  and 
understanding  the  scop>e  of  the  changes  to  its  supporting 
infrastructure.  To  facilitate  the  software  maintenance 
process,  data  regarding  software  changes  can  be 


incorporates 


Figure  2.  Basic  Information  Model 
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maintained  and  periodically  reported.  This  information 
integration  across  the  Air  Warning  Mission,  as  well  as 
identifying  candidates  for  software  re-engineering. 

The  views  extracted  from  the  RDD-100  data  store 
represent  a  set  of  shareable  products  that  can  be  used  to 
extract  data  from  other  architecture  models  supporting 
other  projects  and  S2.  The  sharing  of  these  customized 
reports  repjresents  a  distinct  advantage  in  using  COTS  SE 
tools  like  RDD-100. 

5.2  Use  of  the  Model 

The  Air  Warning  Mission  model  is  one  of  three 
architecture  models  built  to  capture  the  warning  mis¬ 
sions  of  the  Integrated  TW/AA  mission.  Systems 
modeled  include  the  sensor  sources,  communications 
systems,  command  and  control  systems,  and  the  forward 
user  locations.  The  level  of  detail  captured  in  the  model 
is  sufficient  to  trace  information  flows  associated  with 
any  message  within  the  Air  Warning  Mission  S2. 
Inter-mission  traffic  across  models  is  handled  via  the  use 
of  external  pointers  within  the  model  generating  the 
inter-mission  traffic  and  entry  pwints  within  the 
architecture  models  receiving  the  traffic.  To  date,  these 
models  only  capture  normal  opjerational  behavior.  Test 
and  simulation  modes,  error  and  recovery  procedures, 
etc.,  are  not  modeled.  Furthermore,  not  all  of  the  IM 
shown  in  Figure  2  is  currently  captured.  Full  extensions 
that  include  all  requirements  of  these  as-built  systems, 
along  with  M&S  traceability,  are  part  of  work  yet  to  be 
pserformed. 

The  IM  in  Figure  2  does  not  indicate  the  level  of  detail  of 
the  information  captured  in  the  model.  Capturing 
message-level  behavior  translates  into  modeling 
functions  that  are  allocated  to  software  compxjnents  at  or 
above  the  computer  software  component  (CSC)  level  and 
associated  hardware  compx)nents  containing  the  CSCs. 

As  described  below,  modeling  to  this  level  of  detail 
allows  analysts  to  determine  to  the  CSC  level  what 
software  will  be  impacted  by  proposed  changes.  In 
total,  five  C^I  systems  are  modeled  to  this  level  of  detail 
(repiresenting  2.5  million  lines  of  develop>ed  code), 
while  some  30  or  more  systems  are  modeled  to  a  far 
lesser  degree  to  show  end-to-end  information  flows. 

Figtire  3  shows  the  overall  IM  used  to  suppx)rt  change 
management.  Note  that  this  IM  is  a  direct  extension  of 
the  basic  IM  shown  in  Figure  2.  A  brief  description  of 
the  IM  object  classes  shown  in  Figure  3  follows: 

•  Approved  Change.  The  actual  change(s) 
implemented  as  a  result  of  the  Implementation 
Decision.  The  "correlated"  Approved  Changes 
collectively  repjresent  the  total  set  of  changes 
resulting  from  any  single  Proposed  Change  within  a 
system. 

•  Component.  Any  hardware,  software,  or  bioware 
that  is  "allocated  to"  p)erform  any  function.  Levels  of 
detail  range  from  single  systems  down  to  CSCs. 


•  Data  Item.  Represents  either  message,  display, 
alarm,  or  database  information.  Groups  of  any  of 
these  elements  may  be  data  items  as  well. 

•  Effectiveness  Measure.  This  represents  how  a 
satisfaction  of  a  requirement  is  measured  in  terms  of 
success  criteria.  Quantitative  p>erformance  measures 
are  generally  used. 

•  Function.  A  mission-driven  op)erational  function 
(e.g.,  journal  a  message)  p>erformed  at  or  above  the 
message  level.  Note  that  no  system-driven  functions 
(e.g.,  memory  management)  are  c^tured. 

•  Implementation  Decision.  The  decision  and 
suppx)rting  rationale  for  choosing  a  particular 
alternative  from  the  Implementation  Strategy. 

•  Implementation  Strategy.  The  possible 
alternatives  for  implementing  the  Proposed  Change. 

•  Item  Link.  Any  communication  link  (physical  or 
logical)  that  "carries"  a  data  item. 

•  Model/Simulation.  This  represents  a  performance 
simulation  or  model  that  is  sp)ecifically  created  to 
assess  the  effectiveness  measures  associated  with 
quantitative  requirements. 

•  Proposed  Change.  Any  propx)sed  change  to  the 
op)erational  Air  Warning  Mission. 

•  Requirement.  Any  program  requirement  found  in 
the  system  op>erational  requirements  document(s). 

•  Source.  Any  source  of  information  used  in  the 
model.  These  include  formal  deliverables,  documents, 
briefings,  expert  comments,  meeting  minutes,  etc. 

Information  is  extracted  from  the  model  in  views  that 
support  SE  and  software  maintenance  change 
functions.  The  creation  of  the  repx)rt  templates  (i.e., 
views)  is  a  software  development  task  supported  by 
RDD-lOO-supplied  tools  and  windows.  Available 
reports  are  listed  below: 

•  S2  engineering 

-  End-to-End  Trace  Reports 

-  Architecture  Description  Documents 

-  Cross-System  Impact  Assessments 

•  Software  maintenance 

-  Baseline  Modification  Summary 

-  Software  Comp)onent  Change  History 

The  information  contained  within  these  reports  is  used 
to  suppx>rt  change  management  within  the  Air  Warning 
Mission.  Details  concerning  the  content  of  these 
reports  can  be  found  in  [7,  8]. 


Proposed 

Change 


investigated  by 


Implementation 

Strategy 


results  in 


Implementation 

Decision 


Figure  3.  Change  Management  Information  Model 


An  important  aspect  of  this  change  management 
process  deals  with  the  identification  of  what  source 
documentation  must  be  updated.  Multiple  Interface 
Control  Documents  (ICDs)  must  be  maintained  as  part 
of  the  configuration  management  of  the  Air  Warning 
Mission  S2.  The  models  can  relate  the  descriptions  of 
the  system  objects  (components)  with  sections  of  the 
ICDs,  allowing  documentation  managers  to  more 
easily  identify  what  ICDs  need  to  be  changed.  This 
also  helps  ensure  that  the  models  and  documentation 
are  up-to-date  and  consistent.  This  also  reflects  a  key 
part  of  the  rationale  for  this  model  development, 
namely  to  provide  pointers  for  systems  engineers, 
domain-specific  engineers,  and  configuration 
managers  that  allow  them  to  more  efficiently  identify 
cross-system  impacts  and  related  ICD  changes  at  a  low 
level  of  detail. 

The  Air  Warning  Mission  model  described  above  lends 
itself  to  understanding  “what  if?”  questions  associated 
with  the  evolution  of  the  tactical  aerospace  C^I  S2. 
Considerations  for  identifying  and  tracking  objects  of 
small  cross  sections  (such  as  cruise  missiles)  or  the 
addition  of  new  missions,  such  as  Theater  Missile 
Defense,  can  be  explored  through  the  use  of  these 
models.  Questions  regarding  functionality  of 
command  and  control  centers  and  their  supporting 
communications  and  processing  and  display  systems 
can  be  assessed.  Determining  whether  existing 
facilities  can  be  upgraded  or  if  new  ones  must  be  built 
to  meet  new  performance  requirements  can  be 
investigated  through  “alternative  behavior  views” 
within  the  RDD-100  functional  behavior  model. 


The  Air  Warning  Mission  model  is  a  proof-of-concept 
showing  how  MBSE  principles  can  be  implemented 
through  a  single  COTS  SE  tool,  RDD-100.  Although 
this  work  could  scale  up  to  model  the  tactical  aerospace 
C^I  S2,  no  single  tool  can  be  expected  to  meet  all  the 
needs  of  the  decision  makers  controlling  the  evolution 
of  such  a  complex  S2.  Furthermore,  investments  in 
tools  that  currently  model  aspects  of  the  tactical 
aerospace  C^I  S2  should  be  leveraged,  not  duplicated  or 
re-invented  for  the  sake  of  using  other  tools.  Use  of  an 
ISEE  shows  promise  in  meeting  the  challenges 
associated  with  such  efforts.  The  next  section 
addresses  the  ISEE  concept. 

6  .  INTEGRATED  SYSTEMS  ENGINEERING 
ENVIRONMENTS 

The  implementation  of  the  MBSE  method  is 
accomplished  via  an  ISEE.  An  ideal  ISEE  should  allow 
legacy  models  and  tools,  as  well  as  new  tools  and  their 
models,  to  be  used  within  a  single  integrated 
environment. 

6.1  ISEE  Overvievi^ 

The  goal  of  an  ISEE  is  to  allow  modelers  to  use  any 
tool  to  develop  models  and  extract  information  in  any 
desired  way  from  a  common  data  store.  The 
fundamental  ideas  are:  the  information  captured  is 
important,  the  investment  to  gather  information  and 
build  accurate  models  is  significant,  while  the  tools 
used  to  accomplish  these  tasks  will  come  and  go. 

ISEEs  have  the  following  characteristics: 
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•  Designed  to  support  existing  processes 

•  Composed  of  an  integrated  set  of  COTS  (preferred) 
tools  and  methods 

•  Underlying  information  management  structure 
allows  non-obtrusive  sharing  of  data  across  tools 

•  Transparency  of  data  sharing  via  a  common,  single- 
user  interface 

•  Extensible  to  allow  multiple  underlying  COTS 
database  management  systems  (DBMSs)  and  SE 
tools 

•  Network  accessible  on  a  client-server  architecture 

Presently,  no  ISEE  possesses  all  these  characteristics. 
There  are,  however,  two  promising  technical 
approaches  being  explored  to  build  such  an  ISEE. 
These  two  approaches  differ  in  the  underlying 
supporting  technologies  being  used.  The  basic 
approaches  use: 

•  Repository  COTS  products  that  adhere  to  open 
standards  such  as  the  Federal  Information 
Processing  Standard  (FIPS)  156  for  Data 
Repositories 

•  Object-oriented  COTS  products  that  adhere  to  the 
Object  Management  Group  (OMG)  Common  Object 
Request  Broker  Architecture  (CORB  A)  standard 

These  approaches  depend  on  the  use  of  both  open 
standards  and  their  related  products  to  provide  the 
underlying  technology.  The  use  of  such  standards  are 
viewed  as  enablers  in  that  the  COTS  products  used  to 
build  the  ISEE  are  more  easily  integrated  when  common 
standards  are  used.  Even  so,  the  amount  of  “glue  code” 
required  to  integrate  these  COTS  products  is  significant 
and  requires  knowledge  of  product  application 
programming  interfaces  (APIs).  Additional  challenges 
faced  in  the  development  of  an  ISEE  are  mentioned  in 
Section  6.3. 

In-depth  discussions  regarding  these  issues  or  the  two 
approaches  mentioned  above  are  beyond  the  scope  of 
this  paper.  However,  an  example  of  the  use  of  a 
repository  approach  can  be  found  in  [10],  while  an 
approach  using  object-oriented  technologies  is 
described  in  [11].  Although  still  in  the  proof-of- 
concept  phases,  these  ISEE  developments  are  showing 
promise  in  possessing  the  desired  characteristics  of  an 
ideal  ISEE. 

The  structure  of  an  ISEE  is  partly  determined  by  the 
tools  used  to  build  the  models  that  support  the  decision 
making  process.  Understanding  the  scope  of  possible 
tools  to  be  used  provides  insight  regarding  the 
investment  required  to  answer  certain  change  manage¬ 
ment  questions.  For  example,  management  may 
choose  not  to  invest  in  a  certain  tool  or  integrate  a 


legacy  tool  and  associated  models  into  an  ISEE,  if  the 
investment  to  do  so  is  not  compensated  for  by  the 
value  gained  by  the  integration.  The  next  section 
provides  a  sample  listing  of  some  of  the  more  popular 
available  COTS  application  tools,  which  are  candidates 
for  an  ISEE. 

6.2  COTS  Application  Tools 
An  ISEE  should  be  applicable  across  the  lifecycle  of 
the  tactical  aerospace  C^I  S2.  A  suite  of  COTS  tools 
exists  today  that  can  effectively  cover  a  broad  range  of 
the  expectations  discussed  in  Section  2.2.  Some 
examples  of  tools  and  their  applications  follow  to 
demonstrate  the  richness  of  available  COTS 
application  tools.  (Note:  It  is  impractical  to  list  all 
available  tools.  Inclusion  or  exclusion  from  the  list 
does  not  imply  a  thing.)  Following  the  listing,  some 
challenges  and  problems  associated  with  using  such  a 
variety  of  tools  in  a  common  ISEE  are  discussed. 

General  Systems  Engineering  tools  that  permit 
modeling  within  each  phase  of  the  lifecycle,  thus 
capturing  a  wide  variety  of  the  MBSE  characteristics 
previously  discussed: 

•  CORE 

•  RDD-100 

•  SEE  Cradle 

•  SLATE 

•  System  Architect 

Requirements  Management  tools,  which  focus 
attention  on  requirements  and  their  change 
management  throughout  the  system’s  lifecycle: 

•  DOORS 

•  QFD/Capture 

•  RTM 

Process  Modeling  tools  that  allow  process  capture, 
whether  for  systems,  S2,  or  the  way  in  which  business 
is  performed,  and,  in  some  cases,  support  process 
enactment: 

•  BPWin 

•  Design/IDEF 

•  ProCap 

•  Process  Weaver 

•  ProSim 

•  SynerVision 

Simulation  tools,  which  support  executable  models  to 
understand  performance  questions.  Discrete  and/or 
continuous  modeling  are  supported: 

•  BONeS 

•  Extend 

•  Foresight 

•  QASE 

•  SES/Workbench 
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Numerous  domain-sp>ecific  tools  can  be  added  to  this 
list.  For  example,  tools  that  support  configuration 
management,  test,  security,  software  re-engineering, 
and  hardware  design  could  also  be  included  as  viable 
candidates  for  inclusion  in  ISEEs  at  the  application 
level. 

Progress  is  being  made  toward  the  integration  of  COTS 
tools  across  application  domains,  but  at  a  far  simpler 
level  of  sophistication  than  the  efforts  referenced  in 
Section  6.1.  For  example,  interfaces  exist  between 
such  tools  as  RDD-100  and  SES/Workbench,  RTM  and 
Foresight,  System  Architect  and  RDD-100,  DOORS  and 
Teamwork  (a  software  engineering  tool),  Design/IDEF 
and  RDD-100,  etc.  These  pairwise  solutions  are 
accomplished  via  such  mechanisms  as  APIs  or  interface 
definition  languages  (IDLs).  Such  implementations  are 
labor-intensive  and  are  frequently  imperfect  in  their 
translations.  Tool  semantics  and  syntax  differences 
make  100%  translations  impossible.  In  spite  of  these 
issues,  pairwise  interfaces  are  a  step  in  the  right 
direction  and  demonstrate  the  necessity  for  COTS  tools 
to  be  integrated  in  a  closely  coupled  fashion. 

The  rich  set  of  tools  listed  above  has  negative,  as  well 
as  positive,  points.  The  value  of  having  such  a  suite  of 
tools  is  the  user’s  ability  to  choose  the  right  tool(s) 
for  the  right  job  without  investing  in  the  development 
of  one’s  own  unique  tool.  Negative  aspects  include  the 
fact  that  no  tool  is  ever  exactly  what  is  needed,  and  the 
reality  that  COTS  tools  are  not  designed  to  interact 
with  one  another.  These  and  other  challenges  facing 
an  ISEE  are  discussed  in  the  next  section. 

6.3  Challenges  In  Developing  ISEEs 
Challenges  in  developing  a  fully  functional  ISEE  are 
related  to  the  rich  set  of  available  COTS  tools,  the 
historical  use  of  in-house  developed  tools,  the  large 
number  of  models  built  to  address  various  aspects  of 
change  management,  and  the  general  bottom-up 
approach  to  the  use  of  tools.  Some  of  the  more 
important  challenges,  both  technical  and  cultural, 
facing  the  success  of  an  ISEE  include: 

•  COTS  tool  integration  does  not  exist  within  any 
application  domain  (e.g.,  requirements 
management)  or  across  domains  (e.g.,  between 
systems  engineering  and  software  engineering). 

•  Tool  interoperability  and  integration  is  difficult 
since  COTS  tools  semantics  and  external  interface 
definitions  (e.g.,  APIs)  are  different  and,  in  some 
cases,  not  published. 

•  Simultaneous  access  to  ISEE  data  via  multiple  tools 
by  several  engineers  raises  complex  configuration 
management,  version  control,  and  data  access  issues. 

•  The  migration  of  legacy  tools  and  models  to  richer 
environments,  while  leveraging  existing 
investments,  is  not  common  practice. 


•  The  construction  of  flexible  IMs  that  accommodate 
data  and  semantic  structure  differences  across  tools 
and  different  tool  domains  is  an  art  rather  than  a 
science. 

•  Early  lifecycle  cost  justification  (return  on 
investment)  of  a  MBSE  approach  using  an  ISEE 
is  not  easily  demonstrable,  since  returns  are 
experienced  in  later  lifecycle  phases  (i.e.,  cost 
avoidance). 

•  Changing  the  culture  from  a  document-driven 
design  and  maintenance  philosophy  to  a  model- 
driven  approach  can  be  a  challenging  experience. 

•  Taking  a  S2  perspective  across  the  tactical 
aerospace  C^I  S2  demands  some  visibility  into 
systems  and  domains  that  was  previously  not 
required. 

7.  CONCLUSIONS 

MBSE,  as  implemented  by  an  ISEE,  is  a  promising 
approach  to  creating  a  technical  management  structure 
to  control  the  evolution  of  the  tactical  aerospace  C^I 
S2.  Proof-of-concept  modeling  of  MBSE  principles 
using  the  COTS  SE  tool  RDD-1(X)  has  been  shown 
feasible  for  C^I  systems  via  the  modeling  of  the  Air 
Warning  Mission  S2. 

Implementation  of  MBSE  methods  via  an  ISEE  is  the 
overall  goal  now  being  pursued  through  the  use  of 
integrated  standards-based  products  using  underlying 
technologies  such  as  repositories  and  object-oriented 
modeling.  The  current  state-of-practice  regarding  tools 
integration  (i.e.,  migration  towards  an  ISEE)  is 
through  pairwise  integration  of  tools  using  APIs  or 
IDLs. 

Major  challenges  facing  this  work  include: 

•  Incorporation  of  legacy  tools  and  models 

•  The  integration  of  COTS  tools 

•  Scaling  up  of  models  to  accommodate  the  tactical 
aerospace  C^I  S2  levels  of  complexity 

•  Acceptance  of  a  model-driven  approach  to  system 
design  and  evolution 

Next  steps  in  demonstrating  the  feasibility  of  using 
MBSE  and  ISEEs  to  help  manage  the  tactical  aerospace 
C^I  S2  include  expanding  cunent  modeling  efforts  to 
include: 

•  Adding  database  features  capable  of  generating  text 
and  graphics -based  reports  and  performance 
statistics. 

•  Building  behavioral  and  object  models  of  the 
tactical  aerospace  C^I  S2. 
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•  Using  these  models  to  explore  “what  if?”  questions 
pertaining  to  new  threats  and  theater  scenarios. 

•  Performing  fixed,  deployed,  and  employed  asset 
architecture  analyses  to  truly  assess  the  value  added 
in  implementing  a  MBSE  approach. 

Approaching  the  21st  century,  investments  should  be 

made  in  two  major  technical  areas: 

•  The  development  of  an  ISEE  that  is  capable  of 
integrating  legacy  tools  and  models,  along  with 
new  COTS  SE  tools,  and 

•  The  creation  of  a  faster  than  real-time  simulation 
capability  that  can  proactively  determine  the  course 
of  action  of  a  deployed  tactical  aerospace  C^I  S2 
(i.e.,  manage  change  in  a  real-time  environment). 
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1.  SUMMARY 

A  methodology  for  managing  Command,  Control,  Communi¬ 
cations,  Computers  and  Intelligence  (C'^I)  interoperability 
problems  in  a  multi-mission  environment  is  presented.  The 
effort,  designated  Horizon,  was  sponsored  by  the  United  States 
Air  Force  (USAF).  It  is  a  disciplined  top  down  process  for 
managing  and  directing  architectures  starting  at  a  high  level. 

The  essential  elements  of  interoperability  are  defined. 

Mission  operations  boundaries  are  formulated  to  serve  as  a 
framework  for  construction  of  top  level  and  mission  level 
views  of  the  C^I  elements.  Information  flow  between  C*! 
elements  is  described,  and  the  combination  of  the  views  and 
the  interoperability  attributes  are  organized  into  a  database. 

Commercial-off-the-Shelf  (COTS)  software  was  used  to 
develop  a  tool,  designated  Horizon  Link,  to  support  the 
process.  The  database  may  be  expanded  to  accommodate 
specific  user  needs  and  to  support  specialized  analyses.  The 
use  of  the  database  to  support  a  communications  systems 
analysis  within  the  framework  of  the  defined  C'*! 
interoperability  model  is  described. 

The  Horizon  process  has  been  applied  to  the  USAF  in 
formulating  top  level  views  of  C**!  interoperability  supported  by 
a  database  and  in  managing  C**!  issues.  It  may  be  extended  to 
other  Services  or  mission  scenarios.  Recently,  the  Horizon 
process  has  been  extended  into  Europe,  the  Pacific,  and  the 
Joint  Operations  environment.  It  is  the  joint  environment 
application  that  may  be  of  interest  to  NATO.  Considering  this, 
a  deployed  Joint  Task  Force  (JTF)  scenario  is  developed,  and 


the  flexibility  of  the  Horizon  process  is  illustrated,  resulting  in 
a  top  level  portrayal  of  C^I  elements  in  support  of  joint 
operations. 

2.  BACKGROUND 

In  the  United  States  (U.S.),  the  Air  Force  Deputy  Chief  of  Staff 
for  Command,  Control,  Communications  and  Computers 
(DCS/C'‘)  was  directed  by  the  Chief  of  Staff  of  the  Air  Force,  in 
1992,  to  be  responsible  for  directing  and  managing  all  of  the 
architectures  in  the  Air  Force  dealing  with  interoperability. 
Intelligence  support  was  included  in  the  scope  of  responsibility, 
as  well. 

The  MITRE  Corporation’s  Department  of  Defense  (DOD) 
Federally  Funded  Research  and  Development  Center  teamed 
with  Headquarters  Air  Force  under  the  leadership  of  Lieutenant 
General  Carl  O’ Berry,  DSC/C'*,  to  develop  a  process,  method¬ 
ology,  and  tool  which  could  be  applied  to  managing  the  0*1 
architectures  and  interoperability  issues  across  major  Air  Force 
mission  areas,  between  and  among  Air  Force  and  other  DOD 
services  and  agencies,  and  between  the  Air  Force  and  our 
Allies. 

The  objective  was  to  develop  a  top  down  process,  starting  at 
the  highest  Air  Force  level,  and  produce  a  portrayal  or 
presentation  of  C**!  interoperability  which  could  provide  a 
conunon  basis,  supported  by  a  database,  for  identifying  and 
resolving  critical  issues.  The  process  and  tool  were  to  be 
applied  in  providing  direction  regarding  standards  between  all 
Air  Force  C'*!  systems  and  between  the  Air  Force  and  other 
U.S.  and  Allied  systems. 


Paper  presented  at  the  AGARD  MSP  3rd  Symposium  on  "Tactical  Aerospace  Cl  in  Coming  Years'', 
held  in  Lisbon,  Portugal  from  15th  May  to  18th  May  1995,  and  publLdjed  in  CP-557. 
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At  the  outset,  the  major  Air  Force  mission  and  support  areas 
were  established  and  a  set  of  boundaries  defined  which  would 
be  the  concern  of  the  Air  Force  at  this  high  level.  The 
architecture  management  process  that  ensued  focused  on  one 
Air  Force  office  for  the  integration  of  architectures,  and 
identified  to  the  Air  Force  major  Commands  and  agencies 
responsible  for  architectures;  boundaries  and  responsibilities, 
while  at  the  same  time  allowing  design-free  input  in  the 
systems  and  architectures  at  a  lower  level. 

Once  the  process  and  methodology  were  formulated  and 
accepted  within  the  Air  Force,  “strawman”  views  of  O'*! 
interoperability  were  developed,  first  for  the  Air  Force  as  a 
whole;  i.e.,  worldwide;  then  at  the  next  or  second  level  for  each 
defined  mission  and  support  area.  A  supporting  database 
describing  information  flow,  interoperability  attributes,  and 
issues  was  also  developed.  This  entire  data  set  was  coordinated 
within  the  Air  Force  and  a  forum,  called  an  Architecture 
Steering  Group,  was  established  to  review  and  manage  the 
issues  using  the  common  context  of  the  G*!  views  developed 
for  this  purpose.  The  first  meeting  of  the  Architecture  Steering 
Group  was  held  in  September  1994. 

The  tool,  designated  Horizon  Link,  which  contains  the  Air 
Force  O'*!  views  or  diagrams  and  the  supporting  interoperability 
tables,  was  designed,  developed,  and  delivered  to  the  Air  Force 
DCS/C4  in  February  of  this  year. 

The  process  and  tool  have  been  applied  in  extending  GI 
interoperability  architecture  management  to  two  theatres, 
Europe  and  the  Pacific  (the  latter  included  Korea);  one  of  our 
Allies,  the  United  Kingdom;  and  they're  currently  being  looked 
at  for  JTF  as  well. 

3.  COMMAND,  CONTROL,  COMMUNICATIONS, 
COMPUTERS  AND  INTELLIGENCE  (CT) 
INTEROPERABILITY  DEFINITIONS 

The  Horizon  program  emphasizes  CT  interoperability  and 
facilitates  identification,  tracking,  and  resolution  of 
interoperability  problems  across  major  mission  areas  and 
Conunands.  It  is  a  top  down  process  for  managing  and 
directing  C^*!  architectures  starting  at  a  high  level.  It  is  not  an 
architecture  or  system  design  tool,  but  it  is  structured  so  that  it 
can  be  extended  into  specific  systems  analysis  areas,  as  shall  be 
shown  later  in  this  paper. 

Interoperability  has  been  defined  in  many  ways;  however, 
appropriate  to  the  CT  interoperability  addressed  here  is  the  U.S. 
Joint  Chiefs  of  Staff  (JCS)  1989  definition  under  the  G^I  for  the 
Warrior  initiative  which  offers  this  definition:  “The  ability  of 
systems,  units,  or  forces  to  provide  services  to,  and  accept 
services  from,  other  systems,  units,  or  forces  and  to  use  the 
services  so  exchanged  to  enable  them  to  operate  effectively 
together. . 

The  essential  elements  of  CT  interoperability  are  shown  in 
Figure  3-1 .  Since  the  ultimate  objective  is  to  ensure 
interoperability  among  fighting  forces  in  operations  during  and 
through  the  several  classically  defined  stages  of  hostilities;  i.e., 
tension,  crisis  and  conflict;  the  Horizon  process  must  embrace 
these  four  essential  elements: 

1.  Compatible  communications  and  Automated  Information 
System  (AIS)  interfaces. 

2.  Compatible  messages  and  formats. 


3.  Compatible  databases  and  software  applications 
programs. 

4.  Compatible  operating  procedures. 

Element  1  considers  the  electronics  and  systems  that  enable  the 
flow  of  information  between  forces.  Elements  2  and  3  provide 
a  basis  for  achieving  understanding  in  the  information 
exchange.  Element  4  emphasizes  coordination  of  operations 
among,  and  within,  multi-national  forces. 

It  is  the  integrated  set  of  these  essential  elements  that,  when 
achieved,  affords  the  Gl  interoperability  needed  to  confidently 
meet  any  threat. 


Rgure  3-1.  Essential  Elements  of  C*I  Interoperability 

4.  HORIZON;  THE  METHOD  AND  THE  TOOL 
4.1  Objectives  of  the  Capability 

It  is  the  overall  objective  of  the  Horizon  process  to  support  the 
direction  and  management  of  Cl  architectures  and  to  ensure 
the  interoperability  of  G*!  systems.  Its  emphasis  is  on  the 
management  of  CT  issues,  particularly  those  that  involve  cross 
mission  or  force  operating  interfaces;  i.e.,  the  identification, 
analysis,  cataloging,  tracking,  and  resolution  of  those  issues. 

The  management  of  issues  is  accomplished  within  the 
framework  of  a  “system  of  systems”  top  level  view  of  G*! 
elements  of  the  forces  of  interest  supported  by  lower  level 
mission  area  views  and  a  database.  This  information  set, 
organized  to  meet  the  CT  manager’s  and  planner’s  needs, 
provides  a  common  method  and  point  of  reference  for 
commanders  and  staff  to  understand  and  discuss 
interoperability  parameters  and  issues.  At  the  highest  level,  O'*! 
nodes  and  the  information  flow  between  them  are  portrayed  to 
facilitate  the  objectives. 

The  Horizon  database,  with  its  C'*!  “system  of  systems” 
diagrams  and  its  lower  level  mission  area  diagrams  supported 
by  interoperability  attributes,  as  shown  in  Figure  4-1,  provides 
a  framework  for  the  management  of  issues.  Ultimately,  the  top 
level  issues  so  identified  are  brought  to  a  forum  of  principals 
for  resolution.  In  the  USAF,  the  forum  of  principals  is  an 
Architecture  Steering  Group  chaired  by  the  Deputy  Chief  of 
Staff  of  the  Air  Force  for  with  participating  and  voting 
members  from  the  major  Commands  and  field  operating 
agencies  and,  more  recently,  the  United  Kingdom  in  “partici¬ 
pant”  status. 


Discovered  Issues 

•  Examination 

•  Analysis 


Forum  of  Principals 


Kn<?wn  tesues 

•  Field  Experience 
•Test 

•  Other  initiatives 


Issues 

•  Characterize 

•  Resolve 

•  Track 

•  Verify 


Figure  4-1.  Sample  Use  of  Horizon  Data  Base  to  Identity  and  Manage  Issues 


It  is  a  further  objective  of  the  Horizon  process  to  provide  the 
basis  for  derivative  special  analyses  in  order  to  examine,  for 
example,  communications  systems  which  provide  for  the 
connectivity  between  C^l  elements;  or,  the  automated  informa¬ 
tion  systems  that  are  the  end  terminals  supporting  the 
warfighter;  or,  specific  aspects  of  the  operations  of  the  forces 
under  central  or  distributed  control;  or,  the  impact  on  O'*! 
interoperability  of  the  time-phased  introduction  of  new 
capabilities  and  systems. 

4.2  The  Mode! 

The  Horizon  program  and  database  provide  a  top  down  C'*! 
interoperability  architecture  management  process  for  managing, 
controlling,  and  directing  architectures  and  systems  integration 
at  a  high  level.  The  general  Horizon  process  depicted  in  Figure 
4-2  establishes  mission  operations  boundaries  and  provides  for 
the  application  of  standards  which  can  be  utilized  to  ensure  that 
C^l  interoperability  is  achieved  between  systems  for  combined 
arms  operations,  both  national  and  multi-national.  After  the 
defined  mission  area  set  is  established  to  facilitate  the  boundary 
definition  for  management  purposes,  a  baseline  or  “as  is” 
portrayal  of  CT  elements  and  interoperability  attributes  is 


Figure  4-2.  General  Horizon  Process 


developed,  employing  the  methodology  developed  in  Section 
4.3.  This  can  be  used  to  provide  guidance  to  mission  system 
and  lower  level  architectures.  It  is  important  to  note  that  the 
model  and  process  focus  on  managing  0^*1  issues  and 
interoperability  at  the  boundaries  between  defined  mission 
areas  and  between  national  service  elements  and  non-defense 
and  allied  forces  while  allowing  design  freedom  within  mission 
systems. 

Interoperability  issues  derived  are  analyzed  and  resolved 
employing  international  and  DISA  standards  and  a  set  of 
Technical  Reference  Codes,  while  considering  the  critical 
factors  shown  at  the  bottom  of  Figure  4-2.  The  outcome  of 
these  steps  may  influence  either  or  both  the  future  integrated 
O'*!  system  of  systems  and  the  planning  and  acquisition 
process. 


Technical  and  Operational 


Figure  4-3.  Horizon  Interoperability 
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In  the  U.S.,  the  process  has  been  developed  and  applied  in 
managing  the  identification  and  resolution  of  O'*! 
interoperability  issues  between  USAF  major  mission  weapon 
systems  and  they  are  being  looked  at  as  a  means  of  addressing 
issues  between  USAF  and  other  DOD  and  non-DOD  and 
Allied  systems  (Figure  4-3). 


The  model  incorporates  and  depicts  only  M  elements,  as 
illustrated  in  Figure  4-4  and  described  in  Figure  4-5.  As  cited 
earlier,  the  diagrams  do  not  include:  people  (commanders, 
etc.),  organizations,  buildings,  facilities,  or  systems.  The  last 
item  noted,  systems,  while  not  shown  on  the  Top  or  Second 
Level  Diagrams  developed  in  the  methodology  section  (unless 
they  fall  into  one  of  the  element  categories  on  Figure  4-4),  will 
be  manifest  in  the  interoperability  database  that  characterizes 
the  information  flow  between  the  O'*!  elements  diagramatically 
depicted.  Thus,  the  model  strictly  adheres  to  the  portrayal  of 
C*!  elements  and  the  management  of  O'*!  interoperability  issues. 


Figure  4-4.  The  Horizon  C^l  System  Model 


•  Command  and  Control  (C^)  Node 

-  A  Command  Post  or  Central  Command  and  Control 
location,  where  sensor  and  other  information  is 
processed  and  Integrated  from  which  information  is 
sent  to  a  higher  or  lateral  authorities  and/or  direction  is 
provided  to  executing  elements  and  forces 

•  Communications 

^  Means  of  conveying  information  of  any  kind  -  from  one 
person  or  place 

•  Computers 

-  Automatic  information  Processing  Systems  that 
receive,  manipulate  and  present  information  from 
multiple  sources 

•  Intelligence 

-  The  product  resulting  from  the  collection,  processing, 
integration,  analysis,  evaluation,  and  interpretation  of 
available  information  concerning  foreign  countries  or 
areas  (or  forces) 


Figure  4-5.  C^l  Elements 


43  Methodology 

The  first  step  in  the  Horizon  process  is  to  determine  the  mission 
area  set  to  be  managed  from  an  architectural  and  O'*! 
interoperability  perspective.  In  the  case  of  USAF,  the  defined 
major  mission  and  support  areas  are  six-fold  and  include: 

Space  Operations,  Combat  Operations,  Mobility  Operations, 
Special  Operations,  Intelligence  Support,  and  Mission  Support 
(e.g.,  logistics,  medical,  personnel,  etc.)  These  are  shown  in 
Figure  4-6.  The  arrows  in  the  diagram  are  intended  to  point  out 
that  the  process  focuses  on  the  O'*!  issues  at  the  boundaries 


Figure  4-6.  Air  Force  Mission  and  Support  Areas 


between  mission  areas  and  between  the  Air  Force  and  other 
Services  and  our  Allies. 

The  next  step  is  to  construct  the  Top  Level  and  Mission  Area 
(Second  Level)  diagrams.  This  is  illustrated  by  the  series  of 
charts  in  Figures  4-7  through  4-9.  The  portrayal  format  used  in 
all  of  the  diagrams  is  shown  in  Figure  4-7.  The  center  and 
largest  area  of  the  diagram  is  devoted  to  the  enterprise  or 
“integrated  system  of  systems”  of  interest.  For  this  illustration, 
we  have  selected  the  USAF  Cl  integrated  system  of  systems 
diagram  for  the  portrayal  in  the  center.  The  middle,  or  inner 
border,  is  allocated  to  “Other  Department  of  Defense  and 
Service  Unique  Cl  Elements  and  Interfaces.”  Only  the  major 
Cl  elements  in  this  category  with  information  flow  interfaces 
with  elements  in  the  center  of  the  diagram  are  shown  here.  The 
outer  border  is  allocated  to  Cl  elements  of  Allies  and  non¬ 
defense  interfaces  for  the  elements  in  the  center  of  the  diagram. 
Figure  4-8  shows  that  areas  of  the  center  of  the  diagram  are 
allocated  to  the  defined  mission  areas  which,  for  purposes  of 
the  illustration,  are  taken  from  those  shown  earlier  in  Figure  4-6. 
At  this  point,  known  interfaces  external  to  the  Air  Force  may  be 
added  in.  DIA,  for  example,  is  a  non-AF  DOD  interfacing  Cl 
element  and  is  placed  in  the  middle  or  inner  border.  Allies  and 


Figure  4-7.  Top  Level  Diagram  Development-Sf^  One 


Commercial 
Air  Carriers 
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Figure  4-10.  Integrated  Air  Force  Ci  Systems 
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Figure  4-1 1 .  Air  Force  Mobility  Operations  Systems 


NASA  are  examples  of  elements  to  be  appropriately  placed  in 
the  outside  border  of  the  diagram.  Note  that  some  O'*! 
elements,  such  as  those  associated  with  medical  support, 
necessarily  cut  across  all  three  areas  in  the  diagram. 

Next,  each  of  the  mission  areas  are  diagrammed  at  the  very  top 
level  showing  major  O'*!  elements.  In  Figure  4-9,  we  have 
shown  the  formulation  of  the  Mobility  Operations  mission 
diagram.  Known  or  planned  connections  are  then  added  by 
drawing  a  line  between  O'*!  elements  which  signifies  that 
information  flows  between  those  elements,  or  nodes,  as  we 
shall  begin  to  call  them.  Each  of  the  mission  areas  are 
developed  in  this  way  until  all  nodes  at  this  high  or  first  level 
are  shown  while  paying  strict  attention  to  the  model.  A  fully 
populated  diagram  developed  in  this  manner  for  USAF  is 
illustrated  in  Figure  4-10. 

Now  the  Second  Level  Diagrams  (SLD),  or  mission  area 
specific  diagrams,  as  they  may  be  referred  to,  are  developed. 
The  method  of  presentation  remains  the  same,  so  that  a 
common  frame  of  reference  may  be  relied  upon  for  planners, 
developers,  and  operators  alike.  Air  Force  Mobility  Operations 
has  been  selected  to  illustrate  the  SLD,  Figure  4-11.  In  the  case 
of  the  SLD,  the  entire  center  area  is  allocated  to  the  specific 


mission  area,  thereby,  providing  more  space  for  detail.  Further, 
the  middle  and  outer  border  areas  may  be  devoted  to  placing 
only  those  elements  with  which  the  specific  mission  area  has 
interfaces;  i.e.,  where  information  flows  between  mission  area 
nodes  and  CT  elements  in  the  two  border  areas.  One  of  these 
SLDs  is  formulated  for  each  of  the  six  or  selected  sets  of 
mission  and  support  areas. 

The  diagramming  methodology  developed  here  may  continue 
on  to  lower  levels  to  the  point  wherein  the  depictions  begin  to 
take  on  a  physical  nature,  as  well  as  operational  and  technical. 

We  now  turn  to  the  development  of  interoperability  attributes 
which  become  part  of  the  database  supporting  the  diagrams.  In 
our  model,  these  are  structured  to  correspond  to  the  Top  and 
Second  Level  diagrams.  This  section  of  the  process  is 
illustrated  in  Figure  4-12.  On  the  upper  left  is  shown  a 
representation  of  the  diagrams.  The  O'*!  nodes  are  labeled  with 
numbers.  If  there  is  information  flow  between  nodes,  the 
intersection  is  represented,  as  shown  in  the  “N2  Chart,”  shown 
in  the  lower  center  of  the  figure.  The  information  flow  data 
across  each  intersection  is  then  defined  and  entered  into  a  table 
structured  according  to  the  user’s  needs.  This  step  is  illustrated 
in  the  upper  right  of  the  figure. 


Using  the  diagrams  and  information  flow  characterization  in 
the  way  prescribed,  interoperability  attribute  tables  are 
developed  for  both  the  top  and  lower  level  diagrams,  as  shown 
in  Figure  4-13.  As  one  progresses  from  the  top  to  more 
detailed  levels,  the  interoperability  attribute  tables  are 
expanded  to  provide  greater  detail  concerning  the  information 
flow  and  interfaces. 

Format  and  content  examples  for  top  and  second  level 
interoperability  tables  are  offered  in  Figure  4-14  and  4-15.  A 
column  for  entry  of  issues  is  provided  in  each  table,  so  that  the 
database  can  support  the  cataloguing,  tracking,  and  resolution 
process.  Please  note  the  greater  detail  on  the  second  level 
example.  The  communications  link  information  and  the  end 
terminal  Automated  Information  System  (AIS)  data  are 
entered.  These  data  can  facilitate  system  dependency  analyses. 
As  will  be  shown  later  in  the  paper,  a  communications  systems 
analysis  has  been  conducted  using  as  a  base  the  information  in 
the  database  constructed  from  the  interoperability  tables. 

The  ultimate  use  of  the  diagrams  and  interoperability  tables  is 
to  support  the  identification,  cataloguing,  tracking,  and 
resolution  of  Cfl  interoperability  issues.  Referring  again  to 
Figure  4-1,  the  issues  discovery  and  management  process  is 
aided  by  the  very  act  of  diagramming  CT  systems  and 
interfaces  at  the  highest  and  succeedingly  deeper  levels  and 
using  this  information  as  a  commonly  understood  representa¬ 
tion  of  interacting  forces  and  systems.  Conflicting  perceptions 
about  specific  interfaces  are  readily  identified.  More  complex 
interoperability  problems,  either  known  or  discovered,  may  be 
managed  through  a  forum  made-up  of  principal  representatives 
of  the  mission  areas  or  national  forces.  The  forum  would  use 
the  Horizon  database  as  a  tool  to  facilitate  the  issue  resolution 
process. 
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Figure  4-12.  Interoperability  Attributes 
Table  Development 


Top  Level 
Systems 
Diagram 
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Top  Level 
Interoperability 
Attributes 


Second  Level 

Detailed 

Systems 

Interoperability 

Diagrams 

Attributes 

Number 
Source 
Destination 
Mission  Area 
Info  Type 
Issues 


Technical  • 

-  Comm  networks 

-  Source  AIS 

*  Destination  AIS 

-  Protocols 

-  Data  rates 

’  Message  formats 

-  Others 


Issues 

-  Priority 

-  OPR/Office 

-  Action/Status 

-  Suspense  Date 


Operational 

-  Land  Ops  Ctrl 

-  Maritime  Ops  Ctrl 

-  Air  Ops  Ctrl 

-  Joint  Air  Defense/Air  Space 

Management 
’Special  Ops  Ctrl 

-  Integrated  Fire  Support  CTRL 
’  intelligence  Support  Ops 

-  Space  Ops  Ctrl 

-  Nuclear  Ops  Ctrl 
’  Mobility  Ops  Ctrl 
’  Support  Ops  Ctrl 


Figure  4-13.  Overview  of  Interoperability  Attributes 


74b  I  SPADOC 


MWC 


SPADOC 


MWC 


Space 

Operations 


Alerts  &  Warning 
Mission  Coordination 
System  Status 


CINC  Assessments 
Direction  _ 


Launch  Coordination 
System  Status 


Element  Sets 


76a 

N/UCC 

SPADOC 

76b 

SPADOC 

N/UCC 

Space 

Operations 


CINC  Assessments 
Direction 
Message  Release 
Approyal 


89a 

TACC 

TALCE 

Mobility  Operations 

89b 

TALCE 

TACC 

Mobility  Operations 

Moyement  Status 

Asset  Status 

90a 

TACC 

Trans  Ops 

Mobility  Operations 

Moyement  Schedules 

90b 

Treins  Ops 

TACC 

Mobility  Operations 

Force  Movements 

ITV 

91a 

TACC 

TMO 

Mobility  Operations 

91b 

TMO 

TACC 

Mobility  Operations 

Figure  4-14.  Top  Level  InXeroperabWit^  Table- Format  Example 


Number 

Source 

Destination 

Mission 

202b 

AOC 

ABCCC 

Space  Operations 

Space  Operations  NUDET  and 

Ballistic  Missile 

Threat 

Information 


512b  USOTF  AFSOC  Space  Operations  Orders, 

Ops  Ctr.  Cmd.  Ctr.  Directives, 

Status,  Support 
Requests 


648a  TACC  Trans.  Mgt.  Mission  Support  AMC  Airlift 

Offices  Schedule 


Figure  4-15.  Second  Level  Interoperability  Table- Formaf  Examp/e 
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4.4  Horizon  Link  Tool 

The  tool  developed  to  support  the  management  of  the  C'’! 
interoperability  issues  has  been  designated  Horizon  Link. 
Commercial  Off-the-Shelf  (COTS)  software  has  been  used  to 
provide  a  user-friendly  means  of  formulating  the  diagrams  and 
entering  the  interoperability  attributes.  Our  objectives  were 
that  the  tool  be  of  low-cost,  available  commercially,  and  run  on 
both  Personal  Computers  (PC)  and  Macintosh  platforms.  The 
application  packages  and  database  management  software  we 
selected  are  Fox  Pro/SQL  and  Power  Point,  as  shown  in  Figure 
4-16.  The  Fox  Pro  software  offers  the  desired  flexibility  in 
database  manipulation.  SQL  offers  the  networking  capabilities 
and  a  central  database  server  to  support  local  and  remote  users. 
The  Power  Point  application  supports  briefing  development. 


Recalling  the  database  content,  we  have  at  this  point  the  current 
as-built  Top  and  Second  Level  diagrams  and  some  extensions 
in  the  form  of  specific  theatre-level  diagrams,  as  illustrated  in 
Figure  4-17.  In  addition,  the  database  contains  the  interoperability 
attributes  and  data  flow  information,  the  interoperability  issues  for 
each  of  the  top  and  second  level  views,  and  references  to  a  set  of 
operational  standards  and  Technical  Reference  Codes  to  be 
employed  in  the  evolutionary  process. 

The  structure  of  the  database  is  illustrated  in  Figure  4-18.  At 
the  top  level  is  the  “integrated  system  of  systems*’  diagram  with 
accompanying  interoperability  attributes.  The  next  level 
contains  the  six  mission  and  support  area  diagrams  and 
supporting  interoperability  tables.  Figure  4-19  shows  the  PC 
presentation  of  the  node-to-node  charts,  wherein  the 
elements  entered  from  the  diagrams  are  listed  vertically  and 
horizontally,  and  the  intersections  between  nodes  are  identified 
by  an  “X”  entry  in  the  matrix.  The  Horizon  Link  tool  links  the 
“X”  entries  to  the  interoperability  tables,  so  that  selection  of  a 
particular  “X”  will  bring  up  on  the  user’s  screen  the  interoperability 
information  concerning  the  selected  intersection. 


Figure  4-16.  Horizon  UnkTooi  Figure  4-18.  Horizon  Data  Base 
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Figure  4-17.  Horizon  Hierarchy 


The  navigation  features  offered  by  Horizon  Link  are  illustrated 
in  Figure  4-20.  Starting  at  the  Top  Level,  the  user,  for 
example,  may  navigate  down  the  left  side  by  selecting  a 
particular  element  for  analysis.  The  tool  can  produce,  in 
diagram  form,  all  of  the  nodes  with  which  the  selected  element 
interfaces  and  navigating  further  on  the  path  can  retrieve  all  of 
the  interoperability  data  concerning  that  node. 

The  user  may  choose  to  navigate  through  the  system  on  a 
mission  basis.  The  tool  supports  this,  as  shown  on  the  right 


side  of  Figure  4-20.  First,  selecting  a  mission  area  produces  the 
Second  Level  Diagram  of  that  mission  area.  The  user  may  then 
select  a  particular  element  or  elements  within  that  mission  area, 
and  the  tool  will  produce  the  mission  element  interoperability 
attributes  and  issues  associated  with  intersecting  nodes. 

The  tool  supports  the  manipulation  of  the  database,  including 
adding,  deleting  and  modifying,  and  offers  the  user  a  report 
tailoring  capability,  such  as  keyword  search  and  reporting  (e.g., 
locating  and  displaying  all  of  the  top  priority  issues  associated 
with  a  particular  mission  area).  The  N2  charts  are  automati¬ 
cally  regenerated  to  reflect  the  changes  made  and  are  linked  at 
all  levels.  At  this  point,  the  diagram  regeneration  is  manual. 

In  the  near  term,  the  Horizon  Link  configuration  will  be  as 
shown  in  Figure  4-21  supporting  a  user  network  locally.  This 
networkable  tool  can  be  configured,  as  shown  in  Figure  4-22. 
Thus,  the  diagrams  and  interoperability  tables  can  be  made 
available  over  a  wide-area  network,  linking  major  commands 
or  national  force  representatives,  to  a  centrally  managed  but 
distributed  database.  Thus,  users  may  interact,  employing  a 
common  portrayal  of  CT  elements  and  data,  and  identify  and 
participate  in  the  resolution  of  issues. 
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Figure  4-20.  Horizon  Data  Base  Retrieval 


Figure  4-21.  Horizon  Link  Configuration-Near  Term 


Figure  4-22.  Possible  Future  Consideration 
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5.  DERIVATIVE  ANALYSES 

The  Horizon  database  may  be  extended  into  other  areas  or 
enterprises  and  may  be  used  to  support  specific  analyses,  as 
shown  in  Figure  5-1.  These  are  the  extensions  and  analyses 
done  to  date  based  on  the  model,  methodology,  and  results. 

The  first  major  analysis  done  focused  on  the  communications 
which  support  the  information  flow  between  nodes  on  the 
diagrams.  The  database  can  also  support  other  analyses,  such 
as  AIS  and  operations,  as  illustrated  in  Figure  5-2.  This  section 
of  the  paper  demonstrates  how  the  Horizon  Link  databases 
have  been  used  to  support  communications  analyses. 

The  process  combined  Horizon  and  other  communications  data 
as  shown  in  Figure  5-3.  The  reader  may  recognize  the 
diagrams  and  interoperability  tables  on  the  left  and  center  of 
the  figure.  The  communications  systems  supporting  USAF 
were  identified  and  grouped,  as  shown  in  the  left  column  of  the 
inset  on  the  right  of  Figure  5-3.  The  elements,  or  nodes,  are 
shown  across  the  top,  and  the  entries  represent  the  type  of 
information  flow  across  the  intersections;  i.e.,  Data  (D),  Record 
Text  (R),  Electronic  Mail  (E),  Voice  (V),  Fax  (F),  and  Imagery 
(I)  keyed  to  the  communications  systems  in  the  left  column. 
Thus,  step  1  associates  the  communications  systems  with  the 
C4I  nodes  (Figure  5-4). 


The  next  step  delves  more  deeply  into  the  information  flow 
intersection  to  associate  communications  systems  with 
information  flow  lines;  e.g.,  several  communications  lines  or 
links  may  be  employed  to  support  the  information  flow 
between  nodes.  In  an  abstract  sense,  we  have  formed  an  X-Y 
plane,  with  X  representing  the  communications  systems  (i.e., 
what  systems),  and  Y  representing  the  flow  lines  associated 
with  a  particular  node  set  (i.e.,  who).  Figure  5-5  illustrates  this 
step. 

A  third  dimension  may  be  added;  i.e.,  the  Z  axis,  which  can  be 
used  to  represent  the  particular  type  of  traffic  and  end  terminals 
which  are  at  the  nodes  and  are  supported  by  the  communica¬ 
tions  systems  to  afford  the  desired  or  actual  information  flow. 
The  segmented  “poles”  in  Figure  5-6  may  be  analyzed  on  a 
planar  basis  to  examine,  for  example,  imagery  flow  within  a 
mission  area  or  throughout  the  enterprise. 

Finally,  as  shown  in  step  4,  Figure  5-7,  a  communications 
interoperability  assessment  may  be  made  to  examine  the 
adequacy  of  the  communications  support  to  actual  and  required 
information  flow  and  to  identify  issues  that  need  to  be  resolved. 
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Figure  5-1.  Horizon  to  Present 


Figure  5-2.  Possible  Analyses 


•  Combined  Horizon  and  other  communications  data 

•  Reviewed  by  MITRE  and  command  representatives 

•  Submitted  for  review  to  AF/SCT  and  AFC4A  (26  Jan  *95) 


Figure  5-3.  Horizon  Communications  Analysis  Process 


Figure  5-4.  Step  1 :  Associating  Communications  Systems  with  C  I  Nodes 
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Figure  5-5.  Step  2:  Associating  Communications  Systenris  with  Information  Flow  Lines 
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Figure  5-7.  Step  4:  Interoperability  Assessment 
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6  A  JOINT  SCENARIO  RELEVANT  TO  NATO 
In  order  to  illustrate  the  manner  in  which  the  Horizon  C**! 
interoperability  architecture  management  process  may  be 
extended  to  other  mission  areas  and  Command  structures,  we 
have  selected  a  deployed  Joint  Task  Force  (JTF)  scenario. 
Using  the  portrayal  concepts  developed  in  Section  4,  the  model 
is  adapted  to  the  deployed  JTF  applications  by  making  the  C^I 
elements  which  comprise  the  JTF  the  center  of  the  diagram,  as 
illustrated  in  the  framework  of  Figure  6-1 .  The  reader  should 
notice  that  the  inner  boarder  surrounding  the  O'*!  elements  of 
the  JTF  is  allocated  to  rear  area  or  in-garrison  support,  while 
the  outer  boarder  is  reserved  for  non-defense  interfaces.  In  a 


NATO-combined  force  scenario,  this  area  could  just  as  easily 
be  devoted  to  national  or  top  level  NATO  elements. 

Following  the  methodology,  boundaries  are  established  for  the 
major  missions  or  forces  which  make  up  the  JTF.  Following 
guidance  in  references  for  unified  and  joint  operations,  the 
force  elements  and  their  boundaries  may  be  identified  as  shown 
in  Figure  6-2.  Because  Joint  Task  Forces  may  be  assembled  for 
a  variety  of  missions  which  can  include  peace-keeping, 
humanitarian/relief  operations,  crisis  management,  regional 
conflict,  etc.;  the  purpose  of  the  JTF  must  be  defined,  so  that  its 
precise  make-up  may  be  portrayed  in  the  model. 
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Figure  6-1.  Model  for  Generic  TLD  for  Joint  Force 
Environment 


Figure  6-2,  Operations  and  Support  Areas 
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Figure  6*3.  Top  Level  Diagram 


For  purposes  of  illustration  here,  the  mission  of  the  JTF  is  to 
ensure  victory  in  a  regional  conflict.  The  nominal  levels  of  the 
force  elements  are  therefore: 

•  An  Army  Corps 

•  A  Navy  Carrier  Battle  Group 

•  A  Marine  Expeditionary  and  Amphibious  Force 

•  A  “Numbered”  Air  Force 

•  A  Joint  Special  Operations  Task  Force 

Applying  the  diagramming  techniques  described  in  Section  4, 
the  Top  Level  JTF  diagram  is  developed.  The  result  of  this 
phase  of  the  effort  is  portrayed  in  Figure  6-3.  Information  flow 
tables  may  then  be  developed  to  describe  the  information  flow 
and  surface  issues.  (These  are  not  included  here  in  the  interest 
of  brevity.) 

At  the  second  level,  the  diagrams  feature  a  particular  segment 
of  the  wheel  of  Figure  6-2.  Thus,  in  the  case  of  the  JTF 
illustration,  there  will  be  7  second-level  diagrams  in  the  style  of 
Figure  4-9  shown  earlier.  The  supporting  interoperability 
attributes  tables,  with  contents  similar  to  that  iUustrated  in 
Figure  4-15,  are  formulated  next. 

The  foregoing  products;  Top  and  Second  Level  Diagrams  and 
the  supporting  interoperability  attributes  become  the  database 
in  the  Fox  Pro-based  Horizon  Link  tool.  These  data  can  be 
applied  in  force  planning,  identification,  and  resolution  of 
interoperability  issues  at  both  the  mission  and  system  level, 
specialized  analyses  such  as  the  communications  analysis 
discussed  earlier  or  operations  analysis. 

The  JTF  portrayal,  C*I  architecture,  database,  and  tool  may  be 
extended  to  the  combined  force,  multi-mission  environment  in 
which  NATO  finds  itself  in  this  era  following  the  end  of  the 
Cold  War. 

7.  CONCLUSION 

“The  history  of  command  can  thus  be  understood  in  terms  of  a 
race  between  the  demand  for  information  and  the  ability  of 
command  systems  to  meet  it.’T  Applying  the  Horizon 
methodology  described  in  this  paper,  supported  by  the  Horizon 
Link  tool  can  help  us  move  toward  the  level  of  O'*! 
interoperability  needed  for  effective  interaction  of  forces  to 
achieve  mission  goals. 

The  United  States  Air  Force  O'*!  Horizon  is  the  concept  of 
providing  the  warfighter  with  responsive,  advanced  C**!  systems 
services.  The  Horizon  model,  methodology,  and  tool  takes  C^I 
for  the  Warrior,  other  United  States  Department  of  Defense 
Guidance  and  International  Standards  as  the  impetus  for  both  a 
long-range  C^l  planning  process,  as  well  as  a  short-term 
interoperability  issue  identification  and  resolution  process.  The 
long-range  process  codifies  existing  C*!  modeling  efforts  as 
they  feed  requirements  definition,  system  design,  acquisition, 
or  prototype  builds,  testing,  interoperability  certification,  and 
fielding  of  O'*!  systems  for  joint  use.  The  short-term  process, 
supported  by  the  Horizon  Link  tool,  examines  a  manageable  set 
of  critical  O'*!  nodes  and  links  that  represent  the  DOD  mission 
and  support  areas.  Interoperability  issues  that  surface  from 
near-term  assessments  of  the  information  flow  across  those  area 
boundaries  are  addressed  by  an  architecture  steering  group 
chartered  to  resolve  deficiencies. 


Changes  in  missions,  their  needs,  and  insertion  of  emerging 
technologies  are  fed  back  into  the  process.  The  result  is  a  high 
degree  of  confidence  in  interoperability  even  across  different 
mission  areas. 

The  benefits  of  the  C^*!  architecture  management  process 
described  here  derive  from  its  clearly  defining  a  set  of  system 
and  mission  boundaries  and  responsibilities,  while  allowing 
design  freedom  within  mission  systems.  It  identifies  a  single 
organization  to  manage  and  direct  the  overall  architecture. 
It  provides  a  common  top  level  portrayal  of  O'*!  interoperability 
for  commanders  and  staff  to  understand  and  discuss  parameters 
and  issues,  a  tool  to  catalog  and  define  systems  and  issues,  and 
a  forum  to  discuss,  assign,  and  resolve  issues  in  a  joint  or 
combined  environment.  The  process  can  be  extended  to 
NATO. 
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A2C2  Army  Airspace  Command  and  Control  Element 

ABCCC  Airborne  Battlefield  Command  and  Control 
Center 

ADC  Air  Defense  Center 
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ADTOC  Air  Defense  Tactical  Operations  Center 
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CSCC  Corps  Support  Command  Center 
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DISA  Defense  Information  Systems  Agency 

DMA  Defense  Mapping  Agency 
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GPMC 

Global  Patient  Movement  Center 
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Integrated  Tasking  Order 

IWSM 

Integrated  Weapon  System  Management 
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Joint  Communications  Control  Center 

JIC/FST 

Joint  Intelligence  Center/Field  Support 
Team 

JICTRANS 

Joint  Intelligence  Center,  Transportation 
Command 

JMC 

Joint  Movement  Center 

JOC 

Joint  Operations  Center 

JPOTF 

Joint  Psychological  Operations  Task 
Force 

JSTARS 

Joint  Surveillance  Target  Attack  Radar 
System 

LCC 

Launch  Control  Center 

MARFOR 

Commander,  Marine  Forces 

MSF 

Medical  Support  Facilities 

MTF 

Medical  Treatment  Facilities 

MWC 

Missile  Warning  Center 

NAIC 

National  Air  Intelligence  Center 

NAVFOR 

Commander,  Naval  Forces 

NMCC 

National  Military  Command  Center 

OSC 

Operations  Support  Center 

RAMCC 

Regional  Air  Mobility  Coordination 
Center 

ROCC 

Region  Operations  Control  Center 

SOC 

Special  Operations  Command  (Theater) 

SOCC 

Sector  Operations  Control  Center 

SOF 

Special  Operations  Forces 

SOW 

Special  Operations  Wing 

SPADOC 

Space  Defense  Operations  Center 

TACC 

Tanker  Airlift  Control  Center 
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Tactical  Air  Operations  Center 

TFCC 

Tactical  Flag  Command  Center 

TMO 

Transportation  Management  Offices 
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Tactical  Operations  Center 

USSTRATCOM 

U.S.  Transportation  Command 

USTC 

U.S.  Transportation  Command 
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OPERATIONAL  EFFECTIVENESS  THROUGH  INTEROPERABILITY 
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SUMMARY 

The  increasing  use  of  joint  service,  coalition  forces  to 
support  modem  warfare  continues  to  magnify  the 
importance  of  superior  and  flexible  tactical  command, 
control,  communications,  and  intelligence  (C^I) 
systems.  Interoperability  has  become  a  commonly 
identified  key  component  in  the  success  of  this  modem 
warfare.  In  this  context,  interoperability  can  be  defined 
as  the  capability  for  two  or  more  C^I  systems  to  share 
and  manage  common  information  to  maximize  the 
operation^  effectiveness  of  the  combined  force. 
Examples  of  common  interoperability  problems 
experienced  during  a  number  of  military  operations  and 
exercises  are  described.  Potential  short  and  long  term 
interoperability  solutions,  particularly  in  the  areas  of 
data  communication,  data  fusion,  and  data  management 
are  presented. 

1  INTRODUCTION 

With  the  continuing  reduction  of  conventional  forces, 
the  successful  conduct  of  national  and  regional  defense 
and  military  campaigns  relies  increasingly  heavily  on 
the  force  multiplier  advantages  of  tactical  C^I  mission 
systems.  Key  to  this  success  is  the  ability  to  deploy 
and  maneuver  flexible  forces  employing  technically 
superior  C^I  systems.  With  the  decreasing  expectation 
of  massive  force  confrontation  and  the  increasing  need 
for  coalition  forces  to  stabilize  and  resolve  regional 
conflicts,  C^I  systems  must  continue  to  focus  on 
interoperability  as  a  necessity  of  modem  warfare. 

The  acquisition  of  C^I  systems  by  different  services  and 
different  countries  occurs  relatively  independently. 
These  systems  often  provide  narrowly  focused 
capabilities  for  stand-alone  or  limited  group  operations. 
Operation  Desert  Shield/Desert  Storm  highlighted 
existing  deficiencies  in  mission  systems 
interoperability.  And  still,  sever^  years  later,  similar 
problems  plague  Operation  Deny  Right.  Today’s 
systems  employ  a  collection  of  heterogeneous  data  link 
standards  inconsistently  applied  among  services  and 
nations.  Interoperability  is  not  only  a  problem  of  the 
past.  Despite  significant  technological  improvements, 
or  perhaps  as  a  direct  result  of  these  improvements, 
interoperability  remains  an  enduring  issue  which 
challenges  current  and  future  mission  system 
effectiveness. 

The  latest  technology  in  remote  sensing,  aerial  and 
space  observation,  intelligence,  and  communications 


magnifies  the  significance  of  interoperability  to 
operational  effectiveness.  Information  abounds  from 
numerous  sources.  And  yet  the  challenge  remains  to 
provide  the  highest  quality  information,  at  the  right 
place,  at  the  right  time,  to  effectively  accomplish  the 
operational  mission.  A  common  air,  surface,  and 
subsurface  surveillance  picture,  devoid  of  confusing  and 
conflicting  data,  is  needed  to  support  complex  system 
capabilities. 

But  the  fiscal  realities  of  declining  budgets  continue  to 
challenge  progress  in  interoperability.  The  life  cycles 
of  existing  systems  are  being  prolonged  to  minimize 
defense  spending.  With  this  extension  comes  the  need 
to  continue  to  improve  interoperability  among  these 
existing  systems.  Furthermore,  the  deployment  of  new 
technologies  adds  a  whole  new  layer  of  complexity  to 
the  interoperability  issue.  Many  of  the  most  modem 
systems  were  designed  to  facilitate  interoperability  with 
other  modem  systems.  And  so  this  small  subset  of 
recently  developed  systems  operate  relatively  well 
among  themselves.  But  these  new  capabilities  do  not 
address  the  lingering  existence  of  the  older  systems 
which  continue  to  provide  the  backbone  of  modem  C^I 
mission  systems.  The  older,  existing  systems  continue 
to  struggle  to  operate  effectively  together  and  the 
challenges  inaease  as  we  try  to  bridge  the  older  systems 
with  the  new. 

2  INTEROPERABILITY  DEFINITION 

The  term  interoperability  is  used  in  many  different 
contexts  and  with  many  different  interpretations.  In 
Joint  Publication  1-02,  the  United  States  (U.S.) 
Department  of  Defense  (DoD)  Dictionary  of  Military 
and  Related  Terms  defines  interoperability  as  “the 
condition  achieved  among  communications-electronics 
systems  or  items  of  communications-electronics 
equipment  when  information  or  services  can  be 
exchanged  directly  and  satisfactorily  between  them 
and/or  their  users.”  In  the  context  of  interoperability 
among  C^I  systems  to  support  joint  and  combined 
military  force  structures,  this  definition  must  be 
expanded  to  address  the  operational  capabilities  and 
benefits  which  are  achieved  by  such  an  exchange  of  data. 
In  the  joint  service  and  multinational  arena, 
interoperability  provides  the  capability  for  two  or  more 
systems  to  share  and  manage  common  information, 
derived  from  diversified  sources,  to  maximize  the 
operational  effectiveness  of  each  system  and  the 
collective  effectiveness  of  the  combined  force. 
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Interoperability  requires  communication  capabilities  to 
provide  for  the  timely  distribution  of  ground-based, 
airborne,  and  space-based  active  and  passive  sensor  data. 
This  data  distribution  should  include  all  joint  force 
participants  for  whom  this  data  is  necessary  to  support 
the  defined  operational  mission  objectives.  The  C^I 
systems  which  support  these  forces  should  evaluate  and 
combine  all  of  the  available  data  to  maintain  and 
provide  to  the  users  the  highest  quality  information. 
Data  conflicts  and  inconsistencies  must  be  addressed  in 
order  to  provide  an  unambiguous  and  effective  user 
presentation. 

Figure  1  depicts  a  conceptual  architecture  which 
embodies  the  many  components,  or  “layers,”  necessary 
to  achieve  operational  interoperability.  Conununication 
equipment,  such  as  radios,  telephones,  modems, 
encryption  devices,  in  conjunction  with  communication 
protocols,  provides  the  ability  to  transfer  data.  Message 
formats  and  standards  for  message  processing  provide  for 
consistent  interpretation  of  exchanged  data.  Data 
processing  and  data  management,  including  registration, 
correlation,  fusion,  and  conflict  processing,  in 
conjunction  with  system  doctrine,  are  used  to  develop 
the  highest  quality  information.  Finally,  an  effective 
presentation  of  this  high-quality  information  allows  the 
C^I  operators  to  successfully  execute  the  operational 
mission.  It  is  at  this  point  that  full  interoperability  has 
been  achieved. 

3  OPERATIONAL  EXPERIENCES 

Our  experience  in  working  with  the  U.S.  military 
services  to  solve  interoperability  issues  during 
operational  missions,  as  well  as  our  experience  in 
developing  and  deploying  unique  prototype  data  link 
“gateway”  or  “buffer/translator”  systems  for  military 
exercises  and  demonstrations,  provide  continuing 
evidence  of,  and  insight  into,  the  interoperability 
limitations  of  existing  C^I  systems.  It  is  from  this 
perspective  that  common  interoperability  problems  can 
be  identified  and  described.  During  these  operational 
missions  and  exercises,  prototype  capabilities  which 
improve  interoperability  have  also  been  demonstrated. 
These  experiences  provide  a  unique  perspective  from 
which  potential  interoperability  solutions  can  be 
identified.  In  addition,  our  role  in  the  acquisition  and 
development  of  C^I  systems  which  successfully  address 
some  of  these  common  interoperability  issues  lends 
further  support  to  the  proposed  solutions. 

3.1  Operation  Desert  Shield/Desert  Storm 

During  Operation  Desert  Shield/Desert  Storm,  a 
multinational  force,  comprised  of  NATO  and  allied 
forces,  was  established  in  response  to  the  Iraqi  invasion 
of  Kuwait.  The  joint  force  included  Army,  Air  Force, 
Navy,  and  Marine  personnel,  and  combined  ground,  air, 
sea,  ^d  space-bas^  resources  to  accomplish  the 


common  mission.  During  this  operation,  MITRE 
contributed  technical  expertise  necessary  to  design  an 
effective  data  communication  architecture  to  connect  the 
many  participant  C^I  systems  and  to  resolve  data  link 
configuration  issues.  Additionally,  MITRE  deployed  a 
prototype  Joint  Tactical  Information  Distribution 
System  (JTIDS)  display  system,  used  by  the  self- 
defense  officer  on-board  the  pre-production  Joint 
Surveillance  Target  Attack  Radar  System  (STARS) 
aircraft,  to  provide  situational  awareness.  MITRE 
personnel  were  deployed  in-theater  to  assist  in  the  real¬ 
time  resolution  of  operational  problems. 

3.2  Operation  Deny  Flight 

Of)eration  Deny  Flight  is  an  ongoing  joint  NATO  and 
allied  operation  established  to  support  the  United 
Nations  (UN)  humanitarian  mission  and  to  enforce  the 
military  no-fly  zone  in  the  former  Soviet  state  of 
Yugoslavia.  MITRE  has  been  consulted  by  field  units 
deployed  within  the  theater  of  operation  to  assist  in 
alleviating  data  link  connectivity  and  throughput 
problems  between  the  services  and  among  allied 
nations. 

3.3  Joint  Air  Defense  Operation/Joint 
Engagement  Zone  (JADO/JEZ)  Program 

The  JADO/JEZ  test  and  evaluation  program  is 
conducted  by  the  U.S.  Army,  Air  Force,  Marines,  and 
Navy  to  investigate  and  evaluate  the  concept  of 
combined  air  defense  operation,  experimenting  with 
hostile  aircraft  identification  and  engagement  techniques 
and  procedures.  This  program  is  conducted  using 
system  modeling  and  simulation  followed  by  field  test 
exercises.  MITRE  has  provided  engineering  expertise 
necessary  to  design  the  data  link  network  architecture 
used  to  support  this  exercise.  In  addition,  MITRE 
provided  a  prototype  “buffer/translator”  system  which 
translated  and  forwarded  data  between  Tactical  Digital 
Information  Link  (TADIL)  J,  Interim  JTIDS  Message 
Specification  (IJMS),  and  TADIL  B  networks.  The 
prototype  system  also  provided  a  composite  display, 
derived  from  data  from  all  of  these  networks,  which  was 
unavailable  together  in  any  of  the  C^I  mission  systems. 

3.4  Roving  Sands  Exercises 

Roving  Sands  is  a  joint  U.S.  field  exercise  conducted 
annually  to  provide  realistic  joint  service  training  in 
theater  air  defense  operations.  During  the  1994 
exercise,  MITRE  provided  a  prototype 
“buffer/translator”  system  which  translated  and  forwarded 
data  between  TADIL  J,  IJMS,  and  TADIL  B  networks, 
connecting  Army  missile  batteries  to  Air  Force  and 
Navy  airborne  assets.  During  the  most  recent  1995 
exercise,  theater  ballistic  missile  defense  concepts  were 
demonstrated  and  evaluated.  In  support  of  this  exercise, 
MITRE  provided  a  prototype  capability  to  receive 
theater  ballistic  missile  launch  and  impact  point 
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igure  1.  Conceptual  Interoperability  Architecture 
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information  from  missile  tracking  systems  and 
intelligence  sources,  and  distribute  this  information  to 
C^I  mission  systems  via  JTIDS.  The  prototype  system 
also  translated  and  forwarded  surveillance  information 
from  the  JTEDS  network  to  several  TADE.  B  link 
participants.  In  addition,  a  prototype  data  fusion 
capability  was  provided  to  investigate  the  operational 
benefits  which  could  be  achieved  with  such  a  capability. 

3.5  Theater  Air  Defense/Operational 
Concept  Demonstrations 

This  series  of  demonstrations  has  been  undertaken  to 
verify  the  capabilities  of  existing  C^I  systems  to  detect, 
track,  and  report  launch  and  impact  points  for  theater 
ballistic  missiles.  In  addition,  past  demonstrations  have 
examined  the  capabilities  available  to  locate,  identify, 
track,  and  attack  theater  ballistic  missile  transporter- 
erector-launchers.  MITRE  has  deployed  prototype 
systems  to  translate  and  forward  intelligence  data  onto 
the  JTIDS  network.  In  addition,  the  prototype  system 
provided  a  composite  situation  display  derived  from 
tactical  and  intelligence  data. 

4  DEMONSTRATED  INTEROPERABILITY 
PROBLEMS 

Despite  changing  technologies  and  the  evolution  and 
development  of  C^I  systems,  interoperability  remains 
an  enduring  issue.  A  fairly  common  set  of  serious 
interoperability  problems  was  experienced  at  all  of  the 
above  operational  missions  and  exercises.  And  despite 
the  “lessons  learned”  documented  as  a  result  of  each, 
these  problems  continue  to  exist. 

In  support  of  these  types  of  operations,  numerous  data 
links  are  established  within  the  theater  of  operation. 
Figure  2  depicts  a  generic  data  link  topology,  similar  in 
concept  to  those  used  in  these  operations,  designed  to 
provide  interoperability.  Numerous  data  links  are 
combined  in  standard  and  non-standard  configurations. 
Some  of  the  most  common  tactical  data  link  standards 
in  use  include  JTIDS  (TADIL  J  (Link  16)/IJMS), 
TADIL  A  (Link  11  A),  TADIL  B  (Link  IIB),  ATDL-1, 
Improved  Data  Modem  (IDM),  Link  14,  Link  1,  and 
TADIL  C  (Link  4).  In  addition,  the  intelligence 
community  has  defined  another  set  of  unique  data  link 
message  standards.  These  include  the  Tactical 
Information  Broadcast  Service  (TIBS),  Tactical  Receiver 
and  Related  Applications  (TRAP),  and  Tactical  Data 
Information  Exchange  System  (TADIXS). 

Within  these  topologies,  stand-alone  C^I  mission 
systems  attempt  to  participate  in  joint  operations, 
without  the  benefit  of  shared  information.  Other  C^I 
mission  systems  employ  data  links  which  are 
incompatible  with  those  of  their  counterparts. 
Translation  between  different  data  link  standards  is 
available  for  only  a  small  subset  of  C^I  systems. 

Unique  “buffer/translators”  and  “gateways’*  may 


facilitate  communication  but  do  not  address  the  data 
management,  data  fusion,  and  display  processing 
necessary  to  make  effective  operational  use  of  the 
available  data.  Furthermore,  the  “buffer/translator” 
architecture  introduces  a  potentially  critical  single  point 
of  failure.  Communication  bottlenecks,  delays,  and  data 
loss  often  result  from  the  different  data  link  capacities 
on  these  heterogeneous  networks. 

To  further  complicate  the  communication  problems, 

C^I  systems  do  not  consistently  and  correctly 
implement  the  defined  data  link  message  standards.  The 
message  standards  are  an  evolving  set  of  message 
formats  and  implementation  rules.  In  order  to  maintain 
interoperability,  all  systems  on  the  network  must  adhere 
to  the  same  requirements.  However,  many  systems  do 
not  continue  to  update  their  data  link  capabilities  as  the 
standards  evolve.  And  in  many  cases,  different  versions 
of  the  same  data  link  standard  are  not  compatible.  For 
example,  the  well-documented  lack  of  interoperability 
between  IJMS  and  TADIL  J,  both  part  of  a  JTIDS 
network,  clearly  illustrates  this  problem.  Not  only  are 
UMS  and  TADIL  J  not  compatible,  incompatibilities 
exist  between  different  versions  of  JTIDS  terminals  and 
different  releases  of  the  TADIL  J  message  standard. 
Many  systems  choose  to  selectively  implement  the 
specified  message  processing  requirements.  Although 
from  a  narrow  perspective,  this  decision  may  be  reached 
for  a  valid  reason,  it  usually  results  in  data  conflicts,  an 
incomplete  or  inconsistent  surveillance  picture,  and 
operational  limitations  when  operating  with  other 
systems  that  expect  each  network  participant  to  interact 
in  an  established,  predictable  manner. 

Each  system  in  a  combined  theater  of  operation 
contributes  a  subset  of  the  information  necessary  to 
conduct  a  successful  military  campaign.  Collectively, 
these  systems  have  the  potential  to  develop  the  most 
complete  understanding  of  the  operational  situation 
within  the  area  of  interest.  Unfortunately,  as  data 
communication  is  effectively  achieved,  new  problems 
are  exposed.  The  abundance  of  data  often  adds 
confusion,  rather  than  adding  useful  information. 
Duplicate  data,  erroneous  data,  conflicting  data,  and  gaps 
in  data  may  result  in  an  incorrect,  incomplete,  or 
inconsistent  surveillance  picture  among  C^I  systems. 
The  overlapping  coverage  of  different  sensors  provides 
redundant  data  at  varying  levels  of  fidelity.  Most  of  the 
existing  C^I  systems  do  not  have  any  automated 
capability  to  perform  data  fusion  to  address  these  issues. 
Duplicate  and  conflicting  data  complicate  operator 
interpretation  of  the  available  information. 

Furthermore,  limited  and  inconsistent  data  management 
is  performed  by  and  among  the  existing  C^I  systems. 
C^I  system  capacities  can  easily  be  exceeded  and  data 
potentially  lost  as  a  result  of  overlapping  data  received 
from  multiple  data  links.  Different  track  numbering 
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schemes  and  the  lack  of  track  correlation  and  track 
number  translation  hinder  operator  interpretation  of 
available  data  for  the  same  target.  Duplicate  and  dual 
track  data  results  from  inconsistent  and  selective 
application  of  reporting  responsibility  rules  by  C^I 
systems.  Unresolved  reporting  responsibility  conflicts 
and  track  number  conflicts  result  in  incorrect  or 
inconsistent  target  data  between  systems,  including 
significant  target  attributes  such  as  target  identification. 
Information  ambiguity  results  from  unresolved  data 
conflicts  between  C^I  systems.  With  these 
ambiguities,  the  potentii  for  fratricide  and  undetected 
hostile  targets  significantly  increases. 

5  INTEROPERABILITY  SOLUTIONS 

The  multifaceted  solution  to  interoperability  must 
address  five  key  components:  operational  roles  and 
missions,  data  communication,  data  fusion,  data 
management,  and  composite  data  display.  The 
remainder  of  this  paper  will  focus  on  the  data 
communication,  data  fusion,  and  data  management 
aspects  of  the  interoperability  solution,  based  on  our 
experiences  in  operations,  acquisition,  and  development. 

5.1  Data  Communication 

Successful  communication  requires  the  use  of  a 
coimnon  “language”,  including  clearly  defined  “terms” 
which  can  be  consistendy  and  correcdy  interpreted  by 
all.  Successful  data  communicadon  requires  not  only 
compatible  communication  equipment  and 
communication  medium,  but  ^so  a  standardized  set  of 
data  messages  and  message  processing  rules  through 
which  information  can  be  conveyed.  Over  time,  the 
U.S.  DoD  and  the  international  community  have  defined 
many  sets  of  standard  data  communication  “languages.” 
These  different  standards  have  been  applied  to  narrowly 
focused  individual  applications,  in  different  theaters  of 
operation,  without  significant  regard  to  the  potential 
needs  of  other  services  and  nations.  Though  many  of 
these  standards  are  used  to  convey  similar  types  of 
surveillance  information,  the  unique  physical  interfaces, 
message  standards,  and  protocols  prevent 
interoperability  between  the  stan(teds. 

In  the  long  term,  the  operational  capabilities  of  each  of 
the  data  communication  standards  currendy  employed  or 
under  development  need  to  be  reviewed.  This  review 
should  consider  the  current  capabilities  of  each  standard, 
as  well  as  its  ability  to  support  communication  growth 
requirements.  This  review  should  also  address  other 
factors  such  as  cost,  availability,  long  term 
supportability,  and  releasability.  The  anticipated 
operational  requirements  of  the  joint  services  and  allied 
nations,  both  in  the  near  term  and  the  long  term,  must 
be  considered  in  the  context  of  the  available  capabilities. 
Clearly  this  will  require  extensive,  complex, 
cooperative  discussions  among  the  various  services  of 


all  allied  nations.  If  joint  and  combined  operations  are 
to  succeed,  a  smaller  set  of  standards  should  be  selected 
for  continuing  support.  In  evaluating  and  identifying 
the  appropriate  set  of  communication  standards,  the 
military  community  should  also  consider  the  substantial 
advances  underway  in  the  commercial  sector.  Military 
protocols  could  potentially  be  embedded  in  evolving 
commercial  data  communication  standards,  taking 
maximum  advantage  of  the  potential  benefits  of  the 
commercial  communication  infrastructure.  Certainly, 
the  uncoordinated  development  of  additional  new 
standards  should  be  sharply  curtailed,  minimizing 
further  development  costs  and  maximizing  the  utility  of 
the  available  data  communication  capabilities. 

Limiting  the  selection  of  data  communication  standards 
to  a  very  small  subset  of  those  already  in  use  would 
substantially  reduce  the  incompatibilities  which 
currently  exist  and  greatly  simplify  the  task  of  bridging 
the  gaps  between  dissimilar  systems. 

A  joint  service  effort  of  this  type  has  already  been 
initiated  in  the  U.S.  for  tactical  data  links.  In  his  18 
October  1994  letter  to  military  department  secretaries, 
directors  of  the  defense  agencies,  and  the  Director  of  the 
Joint  Staff,  Assistant  Secretary  of  Defense  Emmett 
Paige,  Jr.  designated  JTIDS/Link  16  as  the  U.S.  DoD 
primary  tactical  data  link  for  all  service  and  defense 
agency  command  and  control,  intelligence,  and  weapon 
system  applications.  This  policy  decision  was  intended 
to  reinforce  the  C^I  Common  Data  Link  (CDL)  policy 
of  December  1991,  requiring,  to  the  maximum  extent 
possible,  that  all  information  be  disseminated  through 
Link  16  to  permit  standardized,  interoperable,  data  link 
support  directly  to  the  operator  on  the  battlefield. 
Unfortunately,  this  policy  statement  does  not  address 
the  needs  of  the  international  community.  Nor  does  it 
address  the  continuing  existence  of  older  C^I  systems 
which  cannot  accommodate  such  a  modification. 
Furthermore,  the  significant  funding  which  would  be 
required  to  comply  with  this  policy  is  unlikely  to  be 
available.  As  a  first  step,  this  policy  statement  is 
significant.  Although  the  solution  begins  here,  a  long 
term  implementation  plan  will  also  be  needed. 

A  transition  of  this  type  will  have  substantial  technical 
and  cost  impact  and  will  require  many  years  to 
accomplish.  For  such  a  transition  to  occur,  significant 
funding  must  be  planned  to  accomplish  the  necessary 
modifications.  In  the  current  environment  of  declining 
defense  budgets,  priorities  must  be  revised  to 
accommodate  these  new  requirements.  It  is  also  likely 
that  some  systems  may  never  be  able  to  participate  in 
such  a  transition.  Operational  priorities  will  have  to  be 
established  to  identify  those  C^I  systems  which  are 
most  critical  in  the  tactical  arena.  Also,  systems  which 
are  near  the  end  of  their  life  cycle  may  be  bypassed  in 
favor  of  newer  or  more  capable  systems.  Although  full 
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compliance  may  never  be  achieved,  significant 
improvements  could  be  anticipated. 

For  each  data  communication  message  standard  defined 
and  maintained  for  the  purpose  of  interoperability,  a 
process  must  be  established  to  provide  and  enforce 
consistent  interpretation  of,  and  compliance  with,  the 
requirements  of  the  standard.  For  some  of  the  current 
standards,  a  subset  of  this  process  has  been 
unsuccessfully  attempted.  For  newly  developed 
systems,  formal  testing  is  conducted  to  verify 
compliance  with  certain  data  link  standards. 

Deficiencies  identified  during  this  testing  are 
documented.  However,  the  organizations  involved  in 
such  testing  exercise  no  influence  over  the  operational 
community  to  limit  the  participation  of  non-compliant 
systems  in  the  operational  arena.  Furthermore, 
compliance  of  each  system  is  not  always  re*verified  as 
the  standards  evolve.  During  Desert  Storm,  for 
example,  a  number  of  systems  included  in  the  data 
communication  networks  were  never  certified  to  comply 
with  the  existing  data  link  standards.  Others  had  been 
certified  in  accordance  with  a  previous  version  of  the 
applicable  stantlard,  but  not  the  current  standard.  And 
for  some  standards,  no  formal  certification  verification 
is  performed. 

A  formal,  iterative  standardization  process  should  be 
established  for  each  data  communication  standard  which 
supports  interoperability.  This  process  could  be 
characterized  as  a  cradle  to  grave  effort.  A  joint  service, 
multinational  organization  must  be  empowered  to 
maintain  and  enforce  these  standards.  Such  an 
organization  could  assess  new  user  requirements, 
evaluate  the  capabilities  of  the  current  standards  to  meet 
these  requirements,  and  assess  the  potential  technical, 
cost,  and  schedule  impact  of  approving  a  change  to  the 
applicable  standard  to  incorporate  the  new  requirements. 
In  order  to  maintain  and  continue  to  improve 
interoperability,  modifications  to  the  applicable 
message  stancteds  should  not  be  approved  without  first 
considering  the  necessary  funding  and  developing  a 
feasible,  long  term  plan  to  upgrade  all  affect^  systems. 
This  organization  must  continue  to  verify  consistent 
compliance  with  each  of  the  established  standards, 
repeating  the  verification  of  each  system  after  each 
^proved  modification  to  the  standard.  Most 
importantly,  this  organization  must  have  the  authority 
to  enforce  compliance  and  restrict  operational 
participation  based  on  documented  performance 
limitations. 

Even  as  the  set  of  data  communication  standards  is 
refined,  capabilities  will  still  be  needed  to  bridge  the 
gaps  between  dissimilar  data  links.  A  small  number  of 
systems  include  an  organic  capability  to  receive  and 
process  data  from  different  types  of  data  links.  In  the 
long  term,  an  embedded  capability  of  this  type  is  highly 


preferable.  Most  systems,  however,  still  require  the  use 
of  an  external  “buffer/translator”  or  “gateway”  system  to 
translate  and  forward  data  between  dissimilar  data  link 
standards.  Unfortunately,  a  number  of  unique 
buffer/translator  systems  are  being  developed 
concurrently  and  independently  through  the  efforts  of 
both  the  government  and  industry. 

MITRE  has  developed  a  prototype  buffer/translator 
system  called  the  Multi-link  Translator  and  Display 
System  (MTDS).  This  buffer/translator  system  has 
been  successfully  deployed  at  a  number  of  operational 
missions  and  exercises,  as  described  in  Section  3.  The 
MTDS  is  a  transportable,  proof-of-concept 
buffer/translator  system  based  on  commercial-off-the- 
shelf,  workstation-based  hardware,  C+-H  software,  and 
open  system  standards.  It  operates  in  an  MS-DOS 
environment  and  interfaces  with  multiple  tactical  data 
links  via  software-controlled  interface  boards  which 
process  military  standard  protocols.  The  MTDS 
translates  a  subset  of  surveillance,  intelligence,  and 
management  messages  between  UMS,  TADIL  J,  and 
TADIL  B.  The  MTDS  has  a  situation  and  tabular 
display  and  operator  controls  and  alerts  which  can  be 
us^  to  display  a  composite  surveillance  picture  and 
control  and  filter  the  exchange  of  information  among 
the  data  links.  The  user  interface  capability  of  the 
MTDS  has  also  been  augmented  to  support  track-level 
fusion  related  displays,  as  described  in  Section  5.2.  The 
MTDS  can  record  and  play  back  messages  received  from 
the  tactical  data  link  interfaces. 

The  prototype  MTDS  buffer/translator  system  has  been 
used  to  vali^te  and  demonstrate  the  significant 
improvements  in  interoperability  which  can  be 
achieved.  The  MTDS  has  been  used  to  resolve 
incompatibilities  between  data  communication 
equipment,  encryption  methods,  message  standards  and 
protocols,  and  data  throughput  bottlenecks. 

In  support  of  a  long  term  transition  to  improve 
interoperability,  buffer/translator  systems  could  provide 
cost-effective  solutions  to  interim  incompatibility 
problems.  However,  a  number  of  different  non-standard 
buffer/translators  could  detract  from  the  potential 
benefits,  A  “productized”  buffer/translator  system 
would  offer  the  advantages  of  a  standardized  operational 
procedure,  consistent  capabilities,  and  improved 
supportability.  The  MTDS  could  provide  a  candidate 
design  for  such  a  “productized”  solution. 

5.2  Data  Fusion 

Tactical  C^I  mission  systems  typically  rely  on  inputs 
from  multiple  networks  of  distributed  sensors  and 
tracking  systems.  Track  data  from  these  multiple 
sources  is  then  “merged”  to  provide  a  single  surveillance 
picture.  This  surveillance  picture  is  displayed  to 
operational  personnel  to  conduct  and  coordinate  vital 
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mission  activities  such  as  early  warning,  target 
identification,  weapons  control,  and  airspace 
management  and  control 

In  many  C^I  systems,  operators  must  merge  track  data 
manually.  That  is,  when  data  for  the  same  track  is 
independently  reported  by  more  than  one  source,  it  is 
typically  the  responsibility  of  the  operator  to  recognize 
and  resolve  the  overlapping  data  situation.  Some  C^I 
systems  have  begun  to  automate  this  process. 

Automatic  track-to-track  correlation  allows  track  reports 
received  with  different  track  numbers  to  be  correlated  as 
the  same  target.  For  multiple  track  reports  received 
with  a  common  track  number,  and  for  correlated  tracks 
received  with  different  track  numbers,  a  variety  of 
“preferred  source”  ^proaches  have  been  developed  to 
combine  the  overlapping  data  for  display.  These 
approaches  select  the  “best  track”  for  display  from  the 
available  data,  based  on  ad  hoc  rules  which  are  unique  to 
each  system.  The  selection  of  a  “preferred  source”  is 
often  based  on  the  track  position  accuracy  as  indicated 
by  the  source  reported  track  quality.  The  currently 
defined  track  quality  measures  are  not  based  in  rigorous 
analytical  foundation  and  are  often  not  reliable  indicators 
of  track  accuracy.  As  a  result,  the  most  accurate  track 
may  not  always  be  selected.  Moreover,  with  this 
approach,  gains  in  tracking  performance  that  could  be 
realized  by  combining  multiple  track  estimates  are  lost. 
Typically,  little  is  done  to  merge  or  combine  track 
attributes  from  multiple  sources  that  represents  a  single 
target.  Using  the  “preferred  source”  approach,  track 
attributes  available  from  sources  other  than  the 
“preferred  source”  may  become  unavailable  or  not 
readily  available  to  the  operator,  potentially  resulting  in 
a  degraded  operational  capability. 

Two  recent  acquisition  efforts  undertaken  by  the  USAF 
Electronic  System  Center  (ESC),  with  system 
engineering  support  from  MITRE,  have  demonstrated 
substantial  progress  in  the  data  fusion  arena.  These  air 
defense  systems  both  rely  on  variations  of  the  “preferred 
source”  approach  for  data  fusion,  but  also  acconunodate 
data  from  other  sources  to  provide  the  most  complete 
composite  surveillance  picture,  based  on  all  of  the 
available  data.  The  acquisition  of  a  TADIL  A  capability 
for  the  Royal  Thai  Air  Defense  System  (RTADS)  in  the 
late  1980’ s  provided  a  successful  solution  for  merging 
local  track  data  derived  from  multiple  ground-based 
radars  and  operator  inputs  with  TADIL  A  track  data 
received  from  extern^  sources.  In  RTADS,  the 
available  multiple  overlapping  ground  radar  coverage 
significantly  increased  the  probability  of  high  quality, 
reliable  local  track  data.  When  a  local  track  established 
a  reliable  status  as  the  result  of  regularly  correlated  radar 
reports,  the  local  track  data  was  processed  as  the 
“preferred  source.”  However,  track  attributes  available 
from  the  local  data  were  supplemented  by  additional 


attributes  potentially  available  from  external  sources, 
and  all  attributes  were  merged  into  a  single  system  track 
representing  the  target.  Extensive  data  management 
processing  was  provided  to  alleviate  the  potential  data 
conflicts  which  could  arise  with  this  approach.  The 
acquisition  of  the  Iceland  Air  Defense  System  (IADS), 
still  ongoing,  provides  a  similar  solution  to  this 
problem.  The  track  management  requirements  for  the 
IADS  system  are  somewhat  more  complex  as  a  result  of 
the  numerous  and  different  data  links  which  provide 
track  data  derived  from  external  sources.  The  IADS 
system  also  implements  a  “preferred  source”  approach. 
The  IADS  situation  display  is  primarily  based  on  the 
data  available  from  the  “preferred  source.”  However, 
data  from  each  “remote”  track  which  has  correlated  with 
the  “preferred  source”  track  is  also  available  by  selective 
operator  request  on  both  the  situation  and  tabular 
displays. 

While  these  acquisition  efforts  resulted  in  a  much 
improved  operational  capability,  the  state-of-the-art  in 
data  fusion  continues  to  advance.  Modem  track-level 
fusion  methods  address  the  same  need  to  automatically 
process  the  abundance  of  available  information  from 
multiple  sources.  A  number  of  track-to-track  fusion 
experiments  and  prototype  development  efforts  are 
underway  both  in  the  government  and  in  industry.  The 
evidence  available  thus  far  indicates  that  these  methods 
have  the  potential  to  provide  a  more  comprehensive, 
stable,  quality  surveillance  picture. 

Beginning  in  1993,  ESC  has  sponsored  MITRE 
Mission  Oriented  Investigation  and  Experimentation 
(MOIE)  projects  in  an  effort  to  develop  a  fieldable 
prototype  multisensor  fusion,  data  link  buffer/translator 
system.  During  the  first  year  of  theoretical  study  and 
analysis,  three  track-level  fusion  approaches  were 
studied:  Austere,  Covariance  Bas^,  and  Pseudo 
Measurement  Reconstruction.  In  1994,  five  candidate 
algorithms,  based  on  these  track-level  fusion 
approaches,  were  evaluated  for  their  performance 
potential,  robustness,  ease  of  implementation,  and 
extensibility.  The  competing  demands  of  near-teim  and 
long-term  capabilities  and  considerations  were  evaluated, 
and  a  CovarianceAVeighted  Average,  Normalized 
Statistical  Distance  Association  (NSDA)  algorithm  was 
selected  for  implementation  in  a  prototype  track-fusion 
system.  This  algorithm  optimally  combines  remote 
and  fusion  track  state  information  using  covariance  data 
developed  on  the  various  tracks. 

Using  this  covariance  approach,  a  prototype  fusion 
system  was  developed.  The  track-level  fusion  processor 
prototype  was  designed  to  accept  track  information  from 
the  MTDS  tactical  digital  information  data  link 
buffer/translator  prototype  system  described  above.  The 
fusion  processor  correlates  and  combines  the  remote 
track  data  received  from  the  MTDS  to  develop  fusion 
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tracks  and  generates  fusion-related  display  and  alert 
information.  The  1994  fusion  prototype  performed  its 
processing  in  non-real  time,  with  a  focus  on  improving 
kinematic  performance.  In  1995,  the  prototype  has 
been  enhanced  to  process  tactical  data  in  real  time.  In 
addition,  the  continuation  of  this  MOIE  project  will  add 
an  identification  fusion  algorithm  to  the  fusion 
processor.  The  selected  algorithm  approach  is  based  on 
the  Bayes’  Theorem. 

Commercial  statistical  analysis  and  spreadsheet  software 
capabilities  have  been  used  to  perform  off-line 
quantitative  performance  analyses.  Performance  of  the 
fusion  tracker  was  evaluated  against  simulated  data 
using  Monte  Carlo  techniques.  In  addition,  tactical  data 
recorded  by  the  MTDS  at  a  variety  of  operational 
exercises,  including  those  described  in  Section  3,  above, 
has  been  used  to  support  fusion  algorithm  performance 
assessment. 

The  performance  of  the  fusion  tracker  was  evaluated 
based  on  the  accuracy  and  stability  of  the  position, 
speed,  and  heading  of  constant  velocity  and  maneuvering 
targets.  The  fusion  tracker  performed  successfully 
against  a  range  of  simulation  scenarios.  Fusion  tracks 
performed  better  than  remote  tracks  in  every  measure 
investigated.  Some  improvements  were  incremental; 
many  were  substantial.  The  fusion  tracker  correctly 
combined  multiple  remote  tracks  that  represented  the 
same  target  and  discriminated  among  closely  spaced 
tracks  that  did  not.  The  fusion  tracker  generated  more 
accurate  estimates  of  target  kinematics  against  both 
constant  velocity  and  maneuvering  targets.  The 
improvements  were  especially  dramatic  for  velocity 
accuracy  and  stability.  The  improvements  to 
maneuvering  target  tracking  are  also  noteworthy  because 
combined  requirements  for  accuracy  and  stability  place 
difficult  and  competing  demands  on  a  tracking  system’s 
design.  These  results  would  be  particularly  significant 
to  critical  air  defense  functions,  such  as  weapons 
guidance,  that  depend  on  both  accuracy  and  stability. 

The  performance  of  the  fusion  processor  was  also 
evaluated  against  operational  exercise  data  recorded  by 
the  MTDS.  Because  kinematic  truth  data  was 
unavailable  on  the  vast  majority  of  the  targets,  tracker 
accuracy  was  difficult  to  assess.  However,  demonstrated 
improvements  in  speed  and  heading  stability  for  both 
constant  velocity  and  maneuvering  targets  corroborated 
the  simulation  results.  The  detailed  results  of  the 
performance  assessments  conducted  for  the  fusion 
processor  are  documented  in  [3]. 

Other  improvements  demonstrated  by  the  fusion  tracker 
include  track  continuity  and  improved  track  attribute 
data.  Simulation  scenarios  were  demonstrated  in  which 
a  target  traversed  through  the  adjacent  surveillance 
volumes  of  three  different  remote  tracking  sources 


which  did  not  have  overlapping  coverage.  Each  of  the 
remote  trackers  maintained  the  track  during  one  third  of 
the  scenario.  The  fusion  tracker  generated  one  track  on 
the  target  throughout  the  entire  scenario,  including  two 
small  gaps  in  surveillance  coverage  from  any  of  the 
remote  sources.  This  marked  improvement  in  track 
continuity  could  result  in  a  significant  decrease  in  track 
maintenance  activities  to  be  performed  manually  by 
surveillance  operators.  In  addition,  improved  track 
continuity  allows  track  attribute  information  to  be 
retained  throughout  a  scenario  or  operational  mission, 
with  less  regard  to  varying  track  sources  and  track 
quality.  Similar  to  the  RTADS  and  IADS  systems,  the 
fusion  processor  also  employed  a  simple  but  potentially 
powerful  approach  to  managing  track  attribute  data. 
Once  the  remote  tracks  were  correlated,  attributes 
provided  by  multiple  sources  were  combined  for  display. 
For  attributes  available  from  more  than  one  source, 
Boolean  logic  was  used  to  combine  the  constituent  data. 
This  approach  resulted  in  a  more  complete  set  of 
attribute  data  for  the  fusion  track  than  for  any  of  the 
individual  remote  tracks. 

The  fusion  processor  was  successfully  deployed  at  the 
1995  Roving  Sands  exercise  to  provide  a  re^-time 
display  of  fusion  tracker  data.  Performance 
improvements  achieved  in  laboratory  experimentation 
were  evaluated  in  this  live  operational  environment. 

Clearly,  significant  operational  improvements  can  be 
achieved  by  incorporating  data  fusion  capabilities  in  C^I 
mission  systems.  The  experimentation  and 
demonstrations  conducted  in  recent  years  validate  the 
concept  and  quantify  the  potential  performance 
improvements  which  might  be  expected  from  this  type 
of  capability.  However,  a  significant  amount  of  work 
remains  to  be  accomplished.  Track-level  fusion  has  not 
yet  been  incorporated  in  existing,  operational  C^I 
systems.  Requirements  for  new  systems  and 
modifications  to  existing  systems  that  rely  on 
interoperability  should  address  data  fusion  as  a 
significant  capability  which  will  maximize  operator 
effectiveness.  The  results  achieved  by  the  fusion 
prototype  in  exercises  such  as  Roving  Sands  could  be 
used  to  help  define  feasible,  practical  requirements  in  the 
track  data  fusion  area. 

5.3  Data  Management 

Data  fusion  begins  to  address  the  complications  which 
result  from  the  abundance  of  data  which  can  be  available 
in  complex  networks  comprised  of  different  data  links. 
Additional  data  management  procedures  and  capabilities 
are  equally  imperative  to  further  control  and  resolve  data 
conflicts. 

The  variety  of  track  numbering  schemes  implemented 
by  the  different  data  links  causes  innumerable 
difficulties  in  managing  the  surveillance  picture.  Some 
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of  the  common  formats  include  four  octal  digits,  five 
octal  digits,  and  two  alphanumerics  followed  by  three 
octal  digits.  Some  of  ie  data  links  provide  a  message 
type  which  relates  two  different  track  numbers,  in 
different  formats,  to  the  same  track.  Unfortunately, 
without  an  automated  correlation  capability,  most 
systems  do  not  have  the  ability  to  recognize  such  a 
relationship  and  generate  this  type  of  message. 
Furthermore,  most  systems  do  not  have  the  ability  to 
process  such  a  message  on  receipt  to  automatically 
manage  available  overlapping  data.  In  the  absence  of  a 
track-level  fusion  capability,  or  at  least  an  automatic 
tiack-to-track  correlation  capability,  most  systems 
process  tracks  reported  with  different  track  numbers  as 
different  tracks.  As  a  result,  an  operator  may  view 
several  “superimposed”  tracks  representing  each  actual 
target.  For  tracks  reported  on  the  same  data  link,  or  at 
least  reported  using  the  same  track  number  format,  an 
operator  may  have  the  capability  to  manually  identify  a 
dual  track  condition  and  resolve  the  condition  by  voice 
coordination.  In  many  cases,  “buffer/translator”  or 
“gateway”  systems  further  complicate  this  problem  by 
translating  track  numbers  initiated  by  the  message 
source  to  a  format  required  by  the  other  end  system, 
further  obscuring  to  the  user  of  the  end  system  the 
relationship  between  the  two  different  track  numbers. 
These  dual  track  number  problems  will  only  be  resolved 
as  track-to-track  correlation,  data  fusion,  and  track-level 
fusion  capabilities  become  more  available  in  C^I 
systems.  Until  then,  the  potential  for  overlapping  track 
data  will  require  extensive  operator  interaction  to 
maintain  an  effective  situation  display  presentation. 

The  system  capacity  of  any  C^I  system  can  easily  be 
exceeded  in  an  environment  which  includes  multiple 
data  links  providing  unmanaged  or  poorly  managed 
reporting  of  overlapping  track  data.  In  designing  the 
communication  architecture  to  be  implemented  in 
support  of  an  operational  mission,  the  capacities  of  the 
participating  systems  must  be  considered.  However, 
additional  tools  must  be  provided  to  manage  the  volume 
of  data  received  by  a  C^I  system,  especially  in  areas  of 
multiple  overlapping  coverage  and  high  target  density. 
One  of  the  most  common  tools  implemented  by  many 
C^I  systems  is  a  message  filtering  capability,  based  on 
factors  such  as  geography,  identity,  simulation  status, 
forcetell  and  emergency  conditions.  This  capability 
allows  C^I  systems  to  prioritize  data  processing  based 
on  areas  of  interest  and  the  defined  operational  mission, 
rather  than  accepting  data  on  a  “first  come  first  serve” 
basis.  Display  filters  also  allow  operators  to  focus  on 
the  data  of  most  value  to  the  operational  scenario. 
Attention  displays  should  be  provided  to  alert  operators 
that  the  system  capacity  is  being  approached  or  has  been 
exceeded.  These  types  of  alerts  allow  the  operator  to 
utilize  the  available  tools  to  more  effectively  select  and 


manage  the  data  needed  to  perform  the  operational 
mission  and  that  which  can  be  discarded. 

Another  significant  issue  in  the  management  of  track 
data  is  the  incorrect,  incomplete,  and  inconsistent 
interpretation  of  track  reporting  responsibility  rules  by 
different  C^I  systems.  Some  systems  intentionally 
choose  not  to  implement  reporting  responsibility 
processing.  In  an  environment  where  each  system  is 
dependent  on  all  other  systems  for  adhering  to  a 
common  track  reporting  approach,  such  a  decision  can 
contribute  enormous  confusion  to  a  complex 
surveillance  picture.  Duplicate  and  dual  track  conditions 
will  occur  with  increasing  frequency.  Significant 
position  instability  may  be  observed  as  a  result  of  the 
chaotic  track  reporting.  Track  attributes,  such  as 
identification,  raid  size,  platform  type,  and  mission, 
may  fluctuate  between  two  or  more  entirely  different 
sets  of  characteristics.  In  recent  joint  service 
experiments,  reporting  responsibility  conflicts  were 
demonstrated  to  significantly  detract  from  the  ability  to 
correctly  and  consistently  identify  hostile  targets  for 
engagement.  In  such  a  situation,  a  system  known  not 
to  correctly  implement  all  reporting  responsibility  rules 
should  not  be  flowed  to  transmit  data  on  the  network. 
Organizations  which  maintain  and  enforce  compliance 
with  the  data  link  standards,  as  discussed  above,  should 
clearly  identify  these  issues  to  the  operational 
community  so  that  they  may  be  considered  in  the 
communication  architecture  used  to  support  an 
operational  mission. 

The  data  management  capability  must  also  support  the 
resolution  of  data  conflicts  for  targets  derived  from 
multiple  sources.  Gross  distance  checks  are  typically 
used  to  evaluate  the  target  positions  reported  by  each 
source.  If  different  targets  are  erroneously  reported  with 
the  same  track  number,  a  duplicate  track  number 
condition  should  be  reported  to  the  operator  for 
resolution.  A  dual  track  number  condition  may  also  be 
reported  to  the  operator  if  it  has  been  received  from  a 
data  link  message  or  detected  by  a  track-to-track 
correlation  capability.  Many  of  the  data  link  standards 
explicitly  define  detailed  rules  for  identifying  and 
resolving  identity  conflicts.  Similarly,  Identification 
Friend  or  Foe  (H^  conflicts  may  also  be  identified  and 
resolved,  based  on  specified  message  implementations. 

To  achieve  an  operationally  useful  capability,  data 
management  is  not  optional.  Adding  communication  to 
increase  the  amount  of  available  data  is  of  little  use 
unless  the  data  can  be  managed  effectively  by  the  C^I 
system  to  generate  an  accurate  and  unambiguous 
surveillance  picture  for  the  system  operators. 

6  CONCLUSION 

The  interoperability  challenges  are  clear,  but  the 
complete  solution  is  not.  Interoperability  must  be 


elevated  to  a  higher  level  of  focus,  both  in  the  joint 
service  arena  and  in  the  international  community. 

Many  previous  solutions  have  focused  on  improving 
data  communication,  neglecting  the  other  essential 
components  of  interoperability.  The  common  problems 
which  continue  to  plague  operational  missions  and 
exercises  clearly  highlight  the  lack  of  success  which 
results  from  these  limited  solutions.  Solving  the 
interoperability  problems  will  require  a  multi-faceted 
approach  employing  both  technical  and  procedural 
modifications.  Proposed  technical  solutions  must  be 
weighed  against  available  funding,  schedule  constraints, 
and  the  potential  impact  on  existing  systems. 

Procedu^  modifications  must  be  widely  coordinated 
among  services  and  allied  nations. 

The  success  of  tactical  aerospace  C^I  operations  in  the 
coming  decades  wiU  depend  on  the  ability  of  mission 
systems  to  interoperate  effectively.  The  challenge, 
then,  is  to  define  achievable,  affordable  solutions  which 
address  all  aspects  of  interoperability,  enhancing  the 
operational  effectiveness  of  the  smaller  force  structures 
of  the  future. 
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INTRODUCTION 

La  s6curisation  des  systfemes  d’information  et 
de  communication  (ou  commandement  -  SIC) 
est  une  n6cessit6  afin  qu’ils  puissant  pleinement 
remplir  correctement  las  missions  qui  lours  sont 
confi6ss.  Da  nombraux  axemplas  ont  montrb 
qua  si  cat  aspect  est  nbgligb,  alors  las  risques 
encourus  peuvent  §tre  catastrophiques, 
surtout  an  p6riode  de  crise.  En  effet,  las 
donn^es  sensibles  impliqu§es  par  de  telles 
situations  sont  toutes  stock6es  dans  las  bases 
de  donnbes  de  tels  syst^mes,  qui  sont  aussi 
interconnect§s.  Par  consequent,  une  attaque 
d’une  des  unites  d’un  resaau  de  SIC 
interoperables  peut  etre  penalisante  pour 
I’ensemble  des  systemes  et  peut  m6me,  au  pire, 
paralyser  le  reseau  globalement. 

La  parade  centre  ces  attaques  consiste  e 
contrbler  le  plus  automatiquement  possible  les 
acces  aux  donnees  sensibles.  Autrement  dit, 
une  surveillance  des  sujets  et  des  objets  de 
securite  doit  etre  effectuee  conformement  e  un 
reglement  rigoureux  prealablement  etabli, 
appeie  politique  de  s6curit6  du  systeme 
concerne. 

Cette  politique  de  securite,  dont  I'impie- 
mentation  doit  etre  formellement  prouvee  pour 
certains  niveaux  d’assurance,  se  decline  en 
particulier  en  termes  de  securite  : 

-  informatique,  concernant  I’acces  aux 
donnees, 

-  des  transmissions, 

-  physique  d’acces. 

Traitor  tous  ces  aspects,  et  en  toute  generalite, 
depasse  le  cadre  du  present  expose. 

Nous  nous  iimiterons  ici  h  I'examen  de  situations 
typiques,  souvent  rencontrees,  en  particulier  : 

-  I’integration  de  produits  du  commerce, 

-  la  rehabilitation  des  systemes, 

-  I'interoperabilite  des  SIC. 

La  securite  des  bases  de  donnees  et  les 
processus  d’identification  /  authentification  qui 
sont  deux  points  essentials  en  securite  seront 
egalement  traites  (nous  n'examinerons  pas  ici 
les  systemes  d'exploitation  multiniveaux). 


LES  DIFFERENTES  SITUATIONS  QU'UN 
CONCEPTEUR  PEUT  RENCONTRER 

La  situation  ideale  pour  le  developpeur  est  la 
conception,  puis  la  realisation  d’un  systeme  “de 
toutes  pieces",  s’integrant  dans  un  contexts 
tres  homogene.  Plus  precisement,  il  s’agit  d’une 
situation  ou  il  faut  concevoir  un  systems  A  qui 
communiquera  exclusivement  avec  d’autres 
systemes  A.  Malheureusement,  cette  situation 
ideals  n’est  pratiquement  jamais  realises.  Tres 
souvent  : 

-  le  systems  n’est  pas  nouveau  (mais  est  une 
reprise  d’un  ancien), 

-  il  doit  etre  mis  en  communication  avec 
d’autres  systemes  parfois  tres  differents. 

Cet  etat  de  fait  oblige  le  concepteur  e 
composer  avec  I’existant,  c’est-e-dire  avec  un 
ensemble  de  systemes  tres  vari6,  tres  peu 
homogene.  Certains  de  ces  systemes  sont 
anciens  mais  sont  operationnellement  satis- 
faisants.  D’autres  ont  ete  conqus  suivant  des 
normes  ou  des  standards  qui  ont  6volu6.  Enfin, 
certains  appartiennent  e  des  organisations 
Internationales  comme  I’OTAN. 

Le  probieme  majeur  concerne  done  la 
cooperation  efficace  entre  tous  ces  systemes, 
tout  en  respectant  un  certain  nombre  de 
contraintes  (particulierement  lorsque  la 
cooperation  doit  se  faire  au-deie  des 
frontieres).  Ces  remarques  d’ordre  non 
techniques  montrent  que  des  difficultes 
serieuses  doivent  etre  surmontees. 


Le  contexte  de  ddveloppement  d’un  SIC 


Paper  presented  at  the  AGARD  MSP  3rd  Symposium  on  “Tactical  Aerospace  OI  in  Coming  Years”, 
held  in  Lisbon,  Portugal  from  15th  May  to  ISth  May  1995,  and  published  in  CP-557. 
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Nous  avons  figur6  sur  le  schema  ci-dessus,  un 
certain  nombre  de  situations  gdn6rales  (sans 
pr6tendre  §tre  exhaustif)  auxquelles  le 
concepteur  peut  6tre  techniquement  confronts 
pour  la  sdcurite.  II  peut  s’agir : 

-  du  ddveloppement  d'un  SIC  sdcuris6 
nouveau  (A), 

-  du  d^veloppement  d’une  unitd  particulifere 
d'un  SIC.  Par  exemple,  une  cellule  (B) 
hautement  sdcurisde.  Celle-ci,  en  general, 
est  incluse  dans  un  syst^me  multiniveau  (A). 

Les  principaux  probldmes  poses  concernent : 

-  le  contr6le  d’acces  physique  e  la  cellule, 

-  le  rapatriement  d’informations  moins  confi- 
dentielles  d’autres  systemes, 

-  I'exploitation  des  informations  hautement 
confidentielles  de  cette  cellule, 

-  d’un  systeme  e  r6habiliter  (C)  (dven- 
tuellement  en  connexion  avec  A).  II  s’agit  le 
d’un  logiciel  qui  donne  fonctionnellement 
satisfaction,  sauf  en  matidre  de  securite.  La 
rehabilitation  est  difficile,  pas  toujours 
possible.  Ceci  sera  examine  succinctement 
au  paragraphs  6, 

-  d’un  terminal  public  (D)  deporte,  e  connecter 
e  un  systems  multiniveau  A.  II  faut  eviter  que 
des  chevaux  de  Troie''  soient  introduits  par 
cette  voie  publique.  II  faut  eviter  Sgalement 
que  des  donnSes  sensibles  soient  extraites 
du  systems  A  ou  detruites, 

-  d’une  connexion  de  A  e  un  systems  securise 
mononiveau  (E).  Ce  cas  est  assez  simple  e 
trailer, 

-  d’une  connexion  de  A  e  un  systems  multi¬ 
niveau  (E’)  d’ancienne  generation.  De  tels 
systemes  gerent  des  labels  de  securite  mais 
n’impiementent  pas  toujours  une  politique  de 
securite  Claire.  Si  I'assurance  de  E'  est 
moindre  que  cells  de  A,  alors  le  problems 
majeur  de  la  connexion  e  etablir  entre  E’  et  A 
est  le  suivant  :  A  doit  se  proteger  de  E’  afin 
de  ne  pas  etre  pollue  par  ce  dernier  et  A  ne 
peut  pas  confier  des  donnees  sensibles  e  E’. 
Mime  si  certains  de  ces  systemes  sont  de 
confiance,  les  labels  entre  A  et  E'  ne  sont 
pas  forcement  cohSrents  si  bien  que  des 
ajustements  seront  e  effectuer. 


^  Un  cheval  de  Troie  est  un  programme  qui,  en  plus  de 
r6aliser  les  fonctions  souhait6es,  effectue  des 
operations  violant  la  securite  du  systems  (par  exemple, 
copier  des  donnees  sensibles  dans  des  fichiers 
publics). 


-  g6n6ralement  de  la  connexion  de  A  ^ 
d’autres  systdmes.  Les  difficult^s  dependent 
du  niveau  d’interop6rabilit6  entre  A  et  ces 
systemes.  Si  ce  niveau  est  bas,  il  existe  des 
solutions  simples  faisant  intervenir  des 
opdrateurs  humains  ou  des  passerelles  de 
communication  peu  6volu6es.  Si  le  niveau 
est  plus  important,  alors  on  se  heurte  au 
probl^me  de  la  fusion  des  politiques  de 
s6curit6  encore  du  domaine  de  la  recherche 
(point  examine  succinctement  par  la  suite  ou 
de  la  cooperation  entre  plusieurs  politiques 
(non  examine  ici). 

Tous  ces  points  font  apparaftre  une  varidte  de 
situations  oD  des  systemes  de  differentes 
qualites  doivent  etre  interconnectes. 

Le  problems  majeur  mis  en  evidence  est 
I’interoperabilite  sous  ses  aspects  commu¬ 
nication  (avec  les  procedures  d’identification  / 
authentification  des  systemes)  et  politiques  de 
securite  differentes. 


LES  PARTIES  D'UN  SYSTEME  , 
CONCERNEES  PAR  LA  SECURTE 

La  figure  ci-apres  complete  la  precedents 
puisqu'elle  met  en  evidence  les  differentes 
parties  concernees  par  la  securite  dans  un  SIC 
en  interconnexion  avec  d’autres. 

Comme  prScedemment,  A  est  un  SIC,  il  est  dote 
d'une  cellule  B  deportee  gSrant  des  donnees 
sensibles.  Chaque  cellule  ou  systems  est  dote 
d'une  enceinte  protegee  physiquement  grSce  e 

un  dispositif  symbolise  par  . 

A  I’interieur  de  I’enceinte,  la  securite 
concerns  : 

-  le  systems  d'exploitation  qui  doit  etre 
securise  (TOS  =  Trusted  Operating  System), 

-  I'acces  central  aux  donnees  sensibles.  Ceci 
implique  I’utilisation  de  bases  de  donnees 
(SGBD)  appropriees.  De  telles  bases  existent 
actuellement  dans  le  commerce  au  moins 
jusqu’au  niveau  B1  des  TCSEC  ou  Orange 
Book  (ce  point  sera  detailie  par  le  suite), 

-  le  reseau  local  securise  (LAN  =  Local  Area 
Network).  II  permet  aux  diffSrents  periphe- 
riques  et  machines  interconnectSes  sur  ce 
reseau  (e  I'interieur  de  I’enceinte  du  SIC) 
d’effectuer  des  communications  au  niveau 
approprie, 

-  les  terminaux  securisds  (dcran  /  claviers, 
imprimantes,  ...), 
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-  les  passerelles  G.  Elies  sent  n^cessaires 
pour  les  communications  ext6rieures  avec 
d’autres  syst^mes  multiniveau,  tels  que  A’  ou 
E.  Ces  passerelles  sent  des  calculateurs 
pouvant  poss6der  des  modules  de 
chiffrement  (communication  ^  longue 
distance)  et  d’identification  /  authentification, 

-  les  filtres  spdeiaux  lEE®].  Ms  sent  ndees- 
salres  pour  les  communications  avec  les 
systames  de  qualltds  moindres  que  celles  de 
A.  Ces  filtres  sent  impl6ment6s  sur  des 
calculateurs  contenant  aussi  une  passerelle 
G, 

-  I’int^gration  des  produits  du  commerce. 
L’utllisation  de  tels  produits  dans  les  SIC  tend 
^  s’imposer  pour  de  multiples  raisons. 
Ndanmoins,  d’un  point  de  vue  de  la  s6curit6, 
il  est  assez  ddlicat  de  leur  confier  des 
donndes  sensibles, 

-  la  cellule  d^portde  B  appartenant  au  SIC  A 
contient  des  donndes  trds  sensibles.  II  doit 
§tre  possible  de  transf6rer  des  donndes  de 
A  vers  B,  mais  jamais  I’inverse.  II  n’existe 
qu’un  seui  niveau  de  confidentiality  autorisy 
entre  A  et  B  (dans  notre  cas,  il  s’agit  de 
Secret  Dyfense). 


En  consyquence,  B  ne  travaille  qu’y  un  seui 
niveau  et  le  SGBD  utilisy  n'a  pas  besoin 
d’etre  de  mSme  nature  que  celui  de  A.  Les 
rysultats  des  traitements  effectuds  par  B 
sent  transmis  a  I’extyrieur  souvent  en 
utilisant  des  supports  amovibles  dans 
lesquels  I’information  est  chiffrye.  Notons 
que  mSme  lorsque  B  travaille,  il  n'est  pas 
ndeessaire  de  ddconnecter  B  de  A. 

A  Vexterieur  du  SIC  (A),  d’autres  systdmes 
peuvent  lui  dtre  conneetds.  II  est  mentionny  sur 
la  figure  cl-dessus  un  systdme  rdhabilitd  C 
possddant  deux  niveaux  de  confidentiality. 

La  connexion  de  A  d  d’autres  systdmes 
ndeessite  que  ce  dernier  puisse  identifier  d’une 
fagon  sOre  le  systdme  avec  lequel  il  dolt 
correspondre.  Les  proeddures  d’identification  / 
authentification  entre  les  systdmes  sent  trds 
importantes.  Elies  permettent  d’dviter  qu’un 
intrus  s’introduise  dans  le  rdseau. 

La  communication  entre  A  et  ses  corres¬ 
pondents  peut  dtre  chiffrde.  Ceci  permet  de 
lutter  centre  les  dventuelles  fultes  d’information 
mais  ne  suffit  pas  malheureusement  pour 
garantir  la  disponibilitd  des  donndes. 


Acces  cellule  controle 


Cellule  SD 


SIC  (E') 

pseudo-  ^  ^  I  r _  I 
multiniveau 


SIC(E)-^-. 

mononiveau 


AUTRES 

SYSTEMES 


Les  d'Mrents  points  sensibles 
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LES  PRODUITS  DU  COMMERCE 

On  ne  peut  pas  trailer  indistinctement  tous  les 
produits  du  commerce.  Du  point  de  vue  de  la 
s6curit6,  il  semble  y  avoir  deux  categories  que 
nous  nommerons,  faute  de  mieux,  les  serveurs 
et  les  appHcatifs. 

Les  serveurs  sont  des  produits  dialoguant 
simultanement  avec  plusieurs  utilisateurs  (par 
exemple,  les  Systemes  d’Inforrnatlon  Geogra- 
phiques,  les  outils  de  Gestion  ^lectronique  de 
Documents,  ...).  De  fagon  generale,  ils  sont 
composes  d'un  processus  ayant  pour  r6le 
d'effectuer  des  actions  pour  le  compte  de 
chaque  utilisateur.  Ce  processus  doit  etre  lance 
avant  tous  les  processus  utilisateur  et  ne  peut 
s'interrompre  qu'une  fois  la  derniere  requete 
utilisateur  traitee. 

L'utilisation  de  serveurs,  dont  les  aspects 
securite  n'ont  pas  ete  pris  en  compte  e  la 
conception  ou  dont  les  mecanismes  de  securite 
n'ont  pas  ete  certifies  (selon  les  principes  des 
ITSEC’  europeens  ou  par  le  NCSC^  nord- 
americain),  ne  peuvent  pas  etre  utilises  tels 
quels  dans  un  SIC  securise.  Gerant  plusieurs 
utilisateurs  de  maniere  compietement 
incontrClable,  ils  peuvent  sans  difficulte  violer 
les  regies  de  confidentialite  (sans  parler  de 
I'integrite).  Pour  ces  raisons,  un  SIC  compose 
d'un  tel  serveur,  gerant  des  donnees  et  des 
utilisateurs  de  niveaux  de  securite  differents,  ne 
presente  aucune  garantie  de  securite.  II  existe 
toutefois  des  techniques  pour  utiliser  ces 
serveurs,  tout  en  offrant  un  plus  grand  contrPle 
sur  les  pieges  qu'ils  sont  susceptibles  de 
contenir.  Ce  sont  les  memes  techniques  que 
celles  utilisees  pour  la  rehabilitation  de  SIC  : 
filtre  et  duplication  (voir  le  paragraphe  suivant). 
Cependant,  meme  en  les  utilisant,  un  tel  choix 
lors  de  la  conception  interdira  un  niveau 
d'assurance  eieve  sur  la  securite  du  SIC. 

Contrairement  aux  serveurs,  les  produits  que 
nous  appelons  applicatifs  (compilateurs. 
Publication  Assistee  par  Ordinateur,  Dessin 
Assiste  par  Ordinateur,  ...)  sont  compietement 
couples  aux  processus  utilisateurs.  II  n’existe 
pas  de  processus  representant  le  produil  et 
pr6existant  aux  utilisateurs.  Leur  lancement  est 
effectue  par  le  processus  utilisateur  comma 
une  commands. 


^  Les  normes  ITSEC  (Information  Technology  Security 
Evaluation  Criteria)  ont  6t6  d6velopp6es  par  4  pays 
europeens  (Allemagne,  Pays-Bas,  Royaume-Uni, 
France).  Les  crit6res  font  apparaTtre,  d’une  part  la 
notion  de  fonctionnalit6  et  d'autre  part  celle 
d’assurance. 

2  Le  NCSC  est  I'organisme  certificateur.  Le  document  de 
base  est  connu  sous  le  nom  d’Orange  Book. 


Vis-^-vis  du  systdme,  ils  sont  ex6cut6s  par  le 
processus  utilisateur  et  done  toutes  les  actions 
effectu6es  par  I'applicatif  sont  attributes  t 
I'utilisateur,  de  m§me  pour  les  processus-fils. 
Ainsi,  mtme  si  cet  applicatif  contient  des 
pitges,  ces  derniers  ne  pourront  effectuer  que 
des  actions  permises  t  I'utilisateur. 

Ces  produits  sont  plus  faciles  t  inttgrer  dans 
un  SIC  stcurist.  II  faut,  ntanmoins,  suivre  une 
demarche  prtcise  et  rigoureuse  afin  de 
s'assurer  qu'un  produit  du  commerce  n'affecte 
pas  toute  la  stcuritt  du  systtme.  Un  systdme 
d'exploitation  multiniveau  et  une  gestion 
compartimentte  des  licences  permettent  de 
diminuer  les  risques  introduits. 

LA  REHABILITATION  DES  SYSTEMES 

La  rthabilitation  de  systtmes  consiste  h  partir 
d'un  systtme  existant  peu  ou  pas  stcurist  pour 
tiaborer,  t  moindre  frais,  un  systtme  assurant 
la  mtme  fonction  mais  offrant  une  meilleure 
stcuritt.  Deux  proetdts  principaux  permettent 
de  rthabiliter  les  systtmes  :  l’utilisation  d'un 
filtre.  la  duplication. 

Un  filtre  est  un  module  logiciel  s'intercalant 
entre  les  processus  clients  et  le  processus 
serveur.  Le  principe  est  le  suivant  :  le  serveur 
gtre  toujours  les  mtmes  donntes,  sans  se 
prtoccuper  de  leur  classification.  Le  filtre 
connatt  I'identitt  des  clients,  ainsi  que  leur 
niveau  de  stcuritt.  II  a  pour  fonction  de 
s'assurer  que  les  clients  vont  uniquement 
recevoir  en  r^ponse  ^  leur  requSte,  les 
donn6es  qu'ils  ont  le  droit  de  connaTtre,  selon  la 
politique  de  s6curit6. 

II  doit  6tre  mentionne  qu'un  type  de  menace  est 
particuliSrement  difficile  ^  parer  dans  cette 
approche,  ce  sont  les  pidges  situ6s  q  I'int^rieur 
du  serveur.  De  tels  pidges  peuvent  transformer 
une  etiquette  SD  en  CD,  ce  qui  revient  e 
d6classifier  une  information  SD,  a  I'insu  du  filtre. 

Le  principe  de  la  duplication  est  le  suivant :  on 
replique  le  serveur  en  autant  de  copies  que  de 
niveaux  de  securite  que  Ton  souhaite  gerer.  Un 
frontal  securise  est  intercaie  entre  les  clients  et 
les  serveurs.  Sa  fonction  est  de  transmettre  aux 
serveurs  concernes  les  requetes  des  clients, 
apres  une  eventuelle  transformation.  Ensuite,  il 
doit  recuperer  les  resultats,  effectuer,  si  besoin, 
certains  traitements  avant  de  les  retourner  au 
client. 

Comme  la  quasi  totalite  du  code  s'ex6cutant  sur 
le  frontal  traite  des  6tiquettes  de  s6curit6,  le 
frontal  contient  presque  exclusivement  du  code 
de  confiance.  C'est  un  des  inconv6nients  de 
cette  solution. 
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Un  autre  inconvenient  est  reventuaiite  d'un 
canal  cache  entre  un  client  SD  mal  intentionne 
et  le  serveur  CD.  Le  client  peut,  par 
I'intermediaire  des  requetes  transmises  au 
serveur  CD,  faire  passer  des  informations 
secretes  e  un  cheval  de  Troie,  qui  les 
retournera  plus  tard  e  un  client  CD.  Des 
solutions  existent  pour  diminuer  le  debit  d'un  tel 
canal,  mais  elles  impliquent  une  complexification 
de  I'analyseur  de  requStes  et  un  temps  de 
reponse  accru. 

L'INTEROPERABILITE 

Chaque  systeme  possede  une  politique  de 
securite  qui  lui  est  propre.  Cette  politique  est 
r6git  par  un  ensemble  de  regies  qui  s’appuie 
sur  un  modeie  de  s6curite  adopte  par  les 
concepteurs  du  systeme.  MSme  si  le  modeie  de 
Bell-Lapadula  est  le  plus  r6pandu,  il  n’est  pas 
evident  que  tous  les  systemes  e  mettre  en 
communication  aient  une  politique  de  s6curit6 
s’appuyant  compietement  sur  ce  modeie. 

Certaines  operations  pourraient  etre  permises 
par  un  systeme  et  interdites  par  I’autre. 
Plusieurs  solutions  peuvent  etre  envisagees 
pour  resoudre  ce  probieme.  L'application  de 
celles-ci  depend  du  niveau  d’interop6rabilit6 
auquel  peuvent  pretendre  les  systemes  qui 
doivent  cooperer. 

L’OTAN  distingue  actuellement  6  niveaux,  qui 
prennent  en  compte  I'aptitude  des  systemes  e 
“se  comprendre",  plus  ou  moins 
automatiquement  (le  niveau  6  correspond  e 
I’interoperabilite  complete).  Globalement,  les 
niveaux  1  e  3  correspondent  e  une 
communication  realises  sans  connexion 
physique  entre  les  systemes.  L’echange  est 
initialise  par  des  operateurs  ayant  des  droits 
d’acces  chacun  sur  leur  propre  systems.  Les 
niveaux  4  e  6  utilisent,  par  centre,  une 
connexion  physique  entre  les  systemes  et 
exigent  que  les  utilisateurs  ayant  lance  la 
communication  aient  des  droits  d’acces  sur  un 
certain  domaine  de  I’autre  systems  (mode 
croise). 


interop^rabilite  de  niveau  1  a  3 

L’idee  principals  de  ce  type  d’interoperabilite 
est  que  la  traduction  des  donnees  et  le 
passage  entre  les  differentes  politiques  de 
securite  s’effectue  manuellement  par  un 
operateur  humain  (operateur  de  transfert). 
Ainsi,  le  schema  est  e  peu  pres  le  suivant  :  un 
operateur  extrait  les  donn6es  d'un  systems  en 
se  soumettant  e  la  politique  de  ce  dernier. 


Puis,  il  les  rentre  dans  I'autre  systems  apres 
avoir  effectue  les  operations  n6cessaires  de 
traduction  concernant  I’interpretation  des 
donnees.  Cette  solution  est  interessante,  en 
depit  de  la  lenteur  de  la  communication,  car  les 
eventuels  conflits  sont  toujours  regies  sans 
aucune  ambiguTte.  N6anmoins,  dans  le  cas  ou 
les  operateurs  de  transfert  doivent  posseder 
des  droits  d’acces  sur  chacun  des  deux 
systemes,  certaines  situations  peuvent  limiter  la 
cooperation.  Par  example,  si  I’operateur  de 
transfert  possede  des  droits  sur  la  categorie 
“nucieaire"  pour  I’un  des  systemes,  mais  pas 
pour  I’autre,  alors  I’echange  n’est  pas  possible, 
ce  qui  peut  etre  parfois  tres  penalisant  si  cet 
echange  est  necessaire. 

Ce  type  d’interoperabilite,  s'il  regie  les 
probiemes  de  securite,  est  n6anmoins  trop 
lourd.  En  effet,  la  communication  de  donnees 
volumineuses  est  quasi  impossible. 


Interoperabilite  de  niveau  4^6 

La  presence  d'une  connexion  entre  les  2 
systemes  ne  permet  pas  d'effectuer  une 
"juxtaposition"  des  politiques  realisee  par  une 
traduction  effectuPe  par  des  operateurs 
humains  comme  dans  le  cas  precedent. 

Comme  precedemment,  la  limitation  du  domaine 
e  echanger,  si  elle  est  possible  automa¬ 
tiquement,  est  la  solution  la  plus  simple  techni- 
quement.  Par  example,  on  pourrait  imaginer 
que  seules  des  donnees  non  classifiees  d'une 
certaine  categorie  sont  exportables. 
Neanmoins,  une  telle  solution  est  vue  comme 
tres  reductrice,  car  en  general  les 
operationnels  veulent  aller  plus  loin.  Pour 
pouvoir  realiser  une  connexion  plus  interes¬ 
sante,  il  faut  que  les  2  systemes  puissent 
s'entendre  sur  les  niveaux  des  donnees  a  com- 
muniquer,  et  sur  les  categories  concernbes. 

Deux  modes  principaux  d’echange  peuvent 
etre  envisages  : 

-  le  mode  direct, 

-  le  mode  consent!. 

Lorsqu’un  systeme  permet  le  mode  direct, 
cela  signifie  qu’il  dispose  d’un  domaine 
particulier  Do  de  donnbes  interopbrables. 
Autrement  dit,  I’ensemble  des  informations  qu’il 
detient  n’est  pas  exportable,  hormis  celles  qui 
sont  contenues  dans  ce  domaine  interoperable. 
Tout  systeme  extbrieur  B  peut  y  accbder  a 
condition  qu’il  soit  possible  d’btablir  un  niveau 
d’bchange  adbquat  entre  A  et  B  pour  Do.  Si  tel 
est  le  cas,  B  a  accbs  a  tout  Do  en  fonction  de 
sa  propre  politique  de  sicurM. 
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Ainsi,  il  existe  done  un  domaine  d’6change  bien 
sp6cifi6  (Do)  d‘un  niveau  donn6,  auquel  tous 
les  systdmes  ont  acefes  (en  lecture  seule).  Ce 
mode  est  souvent  utilise  pour  permettre  I’acc^s 
d  une  situation  tactique  entretenue  par  un 
syst^me  dPdib. 


Mode  direct,  ^change  r6gl4  seion 
ia  politique  de  B 


Lorsque  les  2  systdmes  A  et  B  sont 
interop§rables  au  travers  d’un  mode  de 
s§curit6  consent!,  par  example  dans  le  sens 
A  ^  B,  alors  B  ne  peut  pas  intervenir 
directement  sur  A.  II  y  a  transmission  par  B 
d’une  demande  qui  est  ensuite  ex§cut6e  par  A 
s'il  consent  S  y  r^pondre.  En  fait,  A  rbpondra  en 
fonction  de  sa  propre  politique  de  s6curit6. 
L’interop§rabilit6  est  done,  vis-^-vis  de  la 
s4curit6,  un  couplage  plus  faible  que 
pr6c6demment.  Le  systPme  B  est  vu  par  A 
comme  un  sujet,  qui  peut  a  priori  faire  toutes  les 
operations  pour  lesquelles  il  a  les  droits  sur  A. 
Toutefois,  A  garde  un  droit  de  veto  pour 
interdire  dynamiquement  certains  ^changes  (ce 
cas  correspond  au  niveau  6  d'interop6rabiiit6 
OTAN). 


Mode  consent!,  dchange  r4gl4  suivant  ia 
politique  de  A 


LES  BASES  DE  DONNEES  SECURISEES 

Les  bases  de  donn^es  sont  des  composants 
essentiels  des  SIC.  Leur  fonction  premidre  est 
de  gbrer  des  grands  volumes  de  donn6es 
persistantes,  mais  ce  n'est  pas  la  seule.  Un 
SGBD  permet  aussi  le  partage  des  donnPes 
entre  plusieurs  utilisateurs,  une  modPlisation 
permettant  un  acebs  facile  et  puissant  grSce  e 
un  langage  de  requites. 

Dans  le  domaine  des  SGBD  (Syst^me  de 
Gestion  de  Base  de  Donn6es)  s6curis6es,  seule 
I’approche  relationnelle  offre  aujourd'hui  des 
solutions  commerciales. 


Cette  avance  s’explique  facilement  puisque  les 
SGBDR  (SGBD  Relationnelles)  sont  antbrieurs 
aux  SGBDO  (SGBD  Objet)  d'une  dizaine 
d'ann^es  environ. 

Rappel  de  I'existant  : 

Parmi  les  produits  s6curis6s,  il  faut  distinguer 
deux  grandes  classes ; 

-  les  SGBD  n'assurant  que  le  besoin  d'en 
connaitre,  au  moyen  de  contrdles  d'aceds 
discr^tionnaires  {DAC  :  Discretionary  Access 
Control).  Les  fonctions  disponibles  sont 
fondles  sur  I'hypoth^se  que  chaque  donnPe 
poss^de  un  propri^taire  qui  decide  des 
droits  des  autres  utilisateurs  sur  ses 
donn6es, 

-  les  SGBD  gbrant  en  plus  le  droit  d'en 
connaitre,  par  des  contrdles  d'acefes 
obligatoires  {MAC  :  Mandatory  Access 
Control),  aussi  connus  sous  le  nom  de 
multiniveau.  Chaque  utilisateur  et  chaque 
donn^e  possSdent  un  niveau  de  sPeuritb. 

La  premiere  cat6gorie  correspond  aux  niveaux 
C1  et  C2  de  I'Orange  Book,  et  la  seconde  aux 
niveaux  sup^rieurs  (B1,  B2,  B3,  At). 

Les  6diteurs  de  SGBDR  proposent  deux  types 
de  produits  :  une  version  standard,  au  mieux 
6valu6e  au  niveau  C2,  et  une  version 
s6curis6e  multiniveau,  au  mieux  au  niveau  B1. 

Les  principales  fonctionnalit6s  demand6es  par 
le  niveau  C2  sont  la  r6utilisation  d'objets  (object 
reuse),  exigeant  que  tout  conteneur  d'infor- 
mation  soit  remis  t  z6ro  avant  toute  r^util- 
isation,  et  I'audit  des  actions  concernant  la 
s6curit6  (identification,  authentification,  acc6s 
et  destruction  d'objets). 

Tous  les  SGBD  multiniveau  demandant  un 
systPme  d'exploitation  multiniveau. 

Les  attentes 

Les  SIC  ont  mis  en  Evidence  des  besoins  de 
bases  de  donn6es  multimedia  et  rpparties.  En 
effet,  les  informations  e  g6rer  sont  diverses, 
complexes  et  trds  nombreuses.  On  peut  citer 
par  example  :  les  donnPes  de  representation  de 
la  situation  (incluant  souvent  une  cartographie 
vectorielle),  les  donnees  du  renseignement 
(photos,  plans,  fiches  ...),  les  documents,  les 
descriptions  d'objectifs  (objets  complexes),  les 
donnees  meteo,  etc.. 

Une  si  grande  variete  de  donnees  ne  peut  pas 
etre  facilement  geree  par  des  bases  de 
donnees  relationnelles.  Par  centre,  grSce  e  leur 
possibilite  de  typage  riche,  les  SGBDO 
autorisent  une  modblisation  aisee  de  ces 
donnees. 
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De  nombreux  SGBDO  sont  presents  sur  le 
march6.  Malheureusement,  les  fonctions  de 
s6curit6  de  ces  produits  sont  actuellement 
largement  insuffisantes  pour  couvrir  les  besoins 
des  SIC.  Dans  le  meilleur  des  cas,  seuls  des 
contrOles  discrbtionnaires  peuvent  dtre  mis  en 
place. 

Cette  lacune  n'est  pas  due  uniquement  S  la 
jeunesse  des  produits.  Plaquer  des  contrdles 
d'accbs  discr6tionnaires  ou  obligatoires  sur  le 
modeie  des  objets  presents  des  difficultes 
techniques  r^elles. 

Les  SGBDO  offrant  de  r6elles  possibilit6s  pour 
d6velopper  les  SIC  actuels  et  futurs,  leur 
s6curisation  devient  done  un  rbel  besoin,  il  est 
done  pdnalisant  de  les  laisser  de  c6t6  pour  leur 
faiblesse  en  sbeurite.  Les  qualit6s  attendues  de 
telles  bases  s6curis6es  sont  I'ouverture  ci  tous 
les  langages  (C,  C-i-t-,  02C  ou  OQL),  la  compa¬ 
tibility  avec  les  applications  existantes  et  une 
faible  dbgradation  des  performances. 

Les  difficult4s 

Les  points  que  nous  ailons  rapidement  d6crire 
pr6sentent  des  difficult^s  en  cours  d'6tude, 
pouvant  dyboucher  sur  des  solutions 
industrielles  y  moyen  terme. 

-  Langages  de  requytes. 

-  Les  langages  de  requytes  couramment 
employes  dans  les  SGBD  sont  SQL  pour  les 
SGBDR  et  OQL  pour  le  SGBDO.  Aucun  des 
deux  n'est  prevu  pour  interroger  une  base 
multiniveau.  Par  exemple,  la  requyte 
"rechercher  tous  les  employes  dont  la 
classification  est  infOrieure  e  celle  de  leur 
salaire"  est  soit  impossible  e  exprimer,  soit 
une  solution  dependant  du  produit  utilise. 

-  Gestion  des  transactions. 

-  Les  SGBD  utilisent  les  transactions  pour 
regler  les  probiemes  de  contr6les  de 
concurrence  et  de  tolerance  aux  pannes 
(reprise).  Les  protocoles  les  plus  utilises 
dans  ce  domains  sont  le  verrouillage  e  deux 
phases  pour  le  contr6le  de  concurrence  et 
la  gestion  d'un  journal  de  pages  pour  la 
reprise.  II  se  trouve  que  le  verrouillage 
introduit  des  canaux  caches  (le  plus  souvent 
temporels)  entre  transactions  de  differents 
niveaux.  De  la  myme  fagon,  le  rejet 
volontaire  d'une  transaction  par  un 
utilisateur  peut  affecter  les  transactions  de 
plus  haut  niveau. 

-  Leurres 

Pour  cacher  I'existence  d'une  information  y 
un  utilisateur,  une  solution  est  d'introduire 
des  leurres  dans  la  base  au  moyen  de  la 


poly-instantiation  :  pour  chaque  niveau 
inferieur  y  la  version  "vraie",  exists  une 
version  ayant  une  valeur  fictive,  pouvant 
ytre  differents  pour  chaque  niveau. 

Ces  leurres  sont  le  meilleur  moyen  pour 
dissimuler  I'existence  d'une  information 
sensible.  Ms  introduisent  cependant  un 
certain  nombre  de  difficultes  (comment 
determiner  les  vraies  valeurs,  comment 
interroger  les  leurres  ?). 

Les  produits  actuels  ne  permettent  pas  la 
mise  en  place  de  leurre. 

-  Agregation 

Le  problems  d'agrbgation  apparait  chaque 
fois  que  la  sensibility  d'un  agregat  de 
donnees  est  strictement  superieure  y  celle 
de  chacun  de  ses  composants.  Ce  type 
d'agrSgat  nScessite  un  traitement  different 
des  agregats  "normaux",  dont  la  sensibility 
est  egale  au  maximum  de  la  sensibility  de  ses 
composants.  Ce  thbrne  demeure  encore  un 
sujet  de  recherche. 


CONCLUSION 

La  securisation  des  SIC  necessite  plusieurs 
techniques  de  nature  differents  :  chiffrement, 
multiniveau,  materiel,  ....  Ces  techniques 
interviennent  dans  les  SIC  depuis  la  protection 
du  perimStre  de  security  (rOle  du  materiel) 
jusqu'au  coeur  du  systems  stockant  les 
donnees  sensibles  (ou  des  techniques 
informatiques  prennent  le  relai),  sans  oublier  la 
communication  entre  les  systSmes.  Pour 
realiser  cette  securisation,  les  industriels 
doivent  avoir  une  approche  globale  integrant 
tous  ces  aspects.  Ceci  nScessite  non 
seulement  I’application  d’une  methodologie 
rigoureuse,  mais  Sgalement  un  savoir  fairs  y 
spectre  large. 

La  security  des  systemes  est  une 
preoccupation  de  SAGEM  depuis  plusieurs 
annSes.  Elle  comprend  non  seulement  une 
activity  centres  sur  le  chiffrement  de 
I’information  (pour  la  confidentiality  des 
donnees  et  I'identification/authentification  des 
systemes  et  des  personnes  par  cies  secretes  et 
publiques),  mais  Sgalement : 

-  la  realisation  de  systemes  de  recon¬ 
naissance  d’empreintes  digitales, 

-  les  etudes  et  developpements  concernant  la 
technique  multiniveau. 

La  mattrise  de  I’ensemble  de  ces  techniques 
permet  y  SAGEM  la  realisation  de  la  security 
des  systemes  complexes  que  sont  les  SIC. 


10-1 


An  Integrated  Theater  Battle  Management  C2  Architecture  Based 
on  Commercially  Available  Software 

Edwin  J.  Green, 

Michael  C.  Krutsch 
The  MITRE  Corporation 
202  Burlington  Road 
Bedford,  MA  01730-1420 
USA 


SUMMARY 

For  the  past  two  decades,  "stove-pipe”  Command  and 
Control  (C2)  information  systems  have  proliferated 
within  the  I>epartment  of  Defense  (DOD).  This 
proliferation  has  resulted  in  duplication  of 
development  effort,  systems  which  are  not 
interoperable,  and  large  life-cycle  costs.  To  a  large 
extent,  these  systems  have  been  built  with  uniquely 
developed  software.  Much  of  this  unique  software 
constitutes  what  is  commonly  referred  to  as  the 
software  infrastructure  (e.g.,  system  level  services  and 
support  services  for  mission  application  software). 

For  Theater  Battle  Management  (TBM)  C2 
information  systems,  the  software  infrastructures  are 
inherently  the  same  with  regard  to  the  functions  and 
services  they  provide.  Technically,  these  systems 
could  benefit  from  a  common  software  infrastructure. 

With  advances  in  the  commercial  software  market,  the 
realization  of  such  a  common  infrastructure  no  longer 
needs  to  rely  on  uniquely-developed  software.  The 
commercial  marketplace  provides  solutions  for 
significant  portions  of  the  software  infrastructure 
based  on  open  systems  standards  and  mature 
standards-based  products. 


1.0  INTRODUCTION 

DOD  Migration  of  C2  Automated  Information 
Systems  (AISs) 

The  selection  of  DOD  migration  systems  is  an  initial 
step  in  a  process  that  will  effectively  change  the 
methods  by  which  DOD  acquires  and  fields  AISs.  At 
present,  DOD  Program  Managers  each  build  an  entire 
AIS  to  satisfy  an  assigned  set  of  operational 
requirements.  Each  AIS,  by  definition,  consists  of 
"computer  hardware,  computer  software, 
telecommunications,  information  technology, 
personnel,  and  other  resources  which  collect,  record, 
process,  store,  communicate,  retrieve,  and  display 
information." 

The  current  method  of  systems  acquisition  has 
resulted  in  duplication  of  functiondity,  especially  in 
those  components  that  could  be  considered 
"infrastructure."  It  has  also  exaceibated  the 
difficulties  inherent  in  achieving  interoperability 
among  DOD  AISs.  The  goal  of  DOD  systems 


migration  is  to  reduce  costs,  alleviate  duplication  of 
functionality,  and  reduce  interoperability  limitations 
by  moving  DOD  AISs  into  a  distributed,  client-server 
computing  environment  with  a  single  underlying 
infrastructure.  In  this  regard,  mission-  and  function- 
specific  applications  would  be  supported  by  a 
Common  Operating  Environment  (COE)  (e.g.,  system 
services,  support  applications,  common-user  tools),  a 
consistent  data  model,  standardized  data  elements,  and 
consistent  applications  development  conventions  (e.g.. 
Application  ^ogramming  Interfaces  (APIs),  directory 
structures,  naming  conventions).  Application 
development  will  be  governed  by  consistent  standards 
(i.e.,  DOD  Technical  Architecture  Framework  for 
Information  Management  (TAFIM))  and  certain  key 
principles  of  standards-based  versus  non-technical 
architecture  industry  accepted  proprietary-based 
solutions,  Commercial  Off-the-Shelf  (COTS)  versus 
Government  Off-the-Shelf  (GOTS),  and  user-tailored 
versus  standardized  hardware/software  configurations. 

Today,  efforts  are  ongoing  among  the  U.S.  military 
services  to  establish  a  single,  global  Command, 
Control,  Communications,  and  Intelligence  (C3I) 
system  to  support  the  warfighter.  This  single  C3I 
system  will  utilize  a  COE  composed  of  a  set  of 
integrated  support  services  that  support  C3I  mission 
application  software  requirements  and  a  software 
development  environment  which  assists  in  the 
development  of  mission  application  software  by 
capitalizing  on  software  infrastructure  support 
services.  In  the  near-term,  the  COE  includes  support 
applications,  platform  services,  and  reusable  software 
components.  The  mid-term  COE  is  a  target  profile  of 
standards  and  other  services  in  the  following  areas: 
Programming,  User  Interface,  Data  Management,  and 
Operating  System.  The  COE  is  to  migrate  to  eventual 
compliance  with  the  DOD  TAFIM  profile.  Non- 
Developmental  Items  (NDIs),  including  COTS  and 
GOTS.  as  required,  are  the  preferred  COE 
implementation  approach. 

DOD  and  commercial  applications  are  different  but 
also  similar  in  many  ways.  Distinguishing  differences 
often  lie  in  the  time  critical  requirements  to  process 
information  as  witnessed  in  processing  requirements 
for  real-time  embedded  applications  versus  non-real 
time  AISs.  Additionally,  within  the  areas  of  C3I 
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held  in  Lisbon,  Portugal  from  15th  May  to  18th  May  1995,  and  published  in  CP-557. 
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Systems  versus  Commercial  AISs,  we  often  find 
distinguishing  characteristics  in  the  areas  of  fault- 
tolerance  and  high-availability. 

However,  as  the  commercial/business  world  becomes 
more  dependent  upon  their  automated  information 
systems  to  accommodate  soft  real-time  transaction 
processing  (e.g.,  various  stock  market  and  financial 
trade  market  systems),  as  well  as  to  address  the 
requirements  of  highly  available  fault-tolerant 
systems,  the  demands  on  the  commercial  software 
market  are  increasing  to  produce  components  to 
address  these  requirements. 

We  contend  that  much  of  the  functionality  between 
these  commercial  systems  and  DOD  AISs  are  the 
same.  Furthermore,  the  commercial  software  market 
has  matured  to  make  available  numerous  components 
that  will  satisfy  the  requirements  of  DOD  AISs  in  a 
cost  effective  manner.  This  paper  identifies  work 
ongoing  within  the  government,  some  conducted  by 
The  MITRE  Corporation,  that  indicates  the  potential 
use  of  commerci^  technology  within  TBM  C2  AISs. 
This  work  spans  a  spectrum  from:  studies  conducted 
to  determine  the  feasibility  and  cost  of  AJS  migration 
to  a  single  software  infrastructure  and  prototyping 
efforts  to  replace  uniquely  developed  functionality 
with  commercial  software.  Included  in  this  spectrum 
is  work  on  encapsulating  legacy  components  to  allow 
reuse  with  minimal  re-engineering. 


2.0  EFFORTS  TO  DEFINE  A  COMMON 
FUNCTIONAL  ARCHITECTURE 

As  part  of  the  U.S.  Air  Force  consolidation  of  AIS 
systems,  a  TBM  C2  integration  study  was  conducted 
by  the  Air  Force  Materiel  Command’s  Electronic 
Systems  Center  with  support  from  The  MITRE 
Corporation.  This  study  investigated  the 
consolidation  of  four  Air  Force  systems  - 
Contingency  Theater  Automated  Planning  System 
(CTAPS),  Wing  Command  and  Control  System 
(WCCS),  Air  Mobility  Command  (AMC)  C2 


Information  Processing  System  (IPS)  (theater  level 
and  wing  level)  and  Command  Theater  Information 
System  (CTIS)  Digital  Decision  Display  System 
(3DS)  -  into  a  standard  force/unit  level  system.  The 
Air  Force  world-wide  force  and  unit  level  user 
community  participated  in  this  study  through  several 
users  meetings. 

The  motivation  to  consolidate  efforts  comes  from 
several  needs.  Operationally,  these  systems  need  to 
manage  similar  information  and  present  the 
information  to  the  same  or  similar  users.  Technically, 
these  systems  have  substantially  similar  infrastructure 
requirements  and  could  benefit  from  a  common 
approach.  That  is,  a  similar  technical  approach  would 
yield  improved  operational  effectiveness,  as  well  as 
logistics  and  life  cycle  cost  savings.  Such  savings 
would  be  in  the  areas  of  training,  documentation,  and 
software  maintenance.  Also,  fewer  systems  to  deploy 
during  crisis  and  wartime  operations  would  lessen 
airlift  and  hardware  space  requirements. 

One  of  the  critical  findings  of  this  study  was  the  need 
to  establish  a  common  technical  infrastructure  for  both 
force  and  wing  level  systems.  This  software 
infrastructure  would  provide  a  standard  set  of  services 
to  the  force  and  wing  level  applications.  The 
infrastructure  would  provide  the  warfighter  with  a 
basis  to  build  a  system  with  improved  survivability, 
information  consistency  and  integrity,  and  provide  a 
basis  for  building  a  multilevel  secure  system.  It  would 
support  building  mission  applications  with  a  standard 
User  System  Interface  (USI)  to  provide  the  warfighter 
with  a  consistent  look  and  feel  across  force  and  wing 
level  applications  (to  include  standard  map 
backgrounds  and  map  symbology).  Additionally,  a 
common  software  infrastructure  would  allow  for  a 
uniform  set  of  database  management  services  to 
facilitate  the  information  re-engineering  that  must  be 
performed  across  the  heterogeneous  databases.  This 
would  facilitate  the  implementation  of  standardized 
data  elements. 
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Figure  1.  TBM  C2  Target  Software  Architecture 


Figure  1  presents  a  target  software  architecture  that 
will  support  all  TBM  C2  systems,  whether  they  are 
force  (i.e.,  theater)  level  applications,  wing  level 
£q)plications,  or  mission  oriented  applications  that  are 
used  at  both  levels.  Mission  applications  include  the 
functional  software  unique  to  a  specific  command. 
Examples  of  mission  level  applications  include 
software  for  intelligence,  air  campaign  planning  and 
execution/monitoring,  scheduling,  maintenance, 
logistics,  and  weather. 

The  most  significant  feature  of  this  architecture  is  the 
use  of  a  common  underlying  software  infrastructure. 
This  software  infrastructure  is  highlighted  in  the 
shaded  area  of  Figure  1.  It  serves  to  interface  mission 
applications  to  the  underlying  system  support 
components  of  the  operating  system  and  associated 
hardware  (e.g.,  disks,  displays,  and  communications 
interfaces). 

Support  applications  are  utilities  or  services  that 
provide  commonly  needed  functionality  to  support 
C2,  and  that  are  not  specific  to  a  particular  mission 
application.  These  include  software  such  as  electronic 
m^,  message  alert,  common  mapping,  system 
administration  tools,  video  manipulation,  imagery 
handling  service,  and  message  handling  software. 
Some  support  applications  can  be  used  directly  by  the 
user  (e.g..  E-mail).  They  can  also  be  used  to 
implement  a  mission  specific  application.  In  this  case, 
a  standard  API  is  provided  for  each  support 
application  in  order  to  interface  it  with  ihc  mission 
applications. 

The  lowest  level  of  the  infrastructure  software  is  the 
application  support  software.  This  software  is 
comprised  primarily  of  COTS  products  configured 
according  to  TBM  C2  standards  and  implementation 


specifications  to  provide  several  lower-level  services. 
USI  services  include  the  MOUF/X  Windows 
software.  Graphics  services  include  configured  COTS 
software  to  support  both  two  dimension  and  three 
dimension  graphics.  Data  management  services 
include  a  common  set  of  database  management  system 
software,  database  replication  services,  and  database 
backup/recovery  services.  It  may  also  contain 
database  access  modules  and  APIs  to  mission 
applications  which  provide  standard  routines  for 
accessing  and  updating  relational  databases,  track 
databases,  map  databases,  and  other  data  files.  The 
Data  Interchange  Services  and  Networking  Services 
provide  complementary  functions  to  support  message, 
file,  and  remote  terminal  protocols.  They  also  include 
distributed  computing  services,  and  network 
management  services. 

System  support  refers  to  underlying  operating  system 
software,  file  management,  and  other  software 
interfaces  to  computer  hardware  peripherals  and 
external  communications. 

The  infrastructure  will  provide  the  warfighter  with 
improvements  in  information  consistency  and 
integrity  and  system  survivability.  Information 
consistency  and  integrity  means  that  all  users  will 
view  the  same  value  of  operational  items  (e.g., 
number  of  aircraft  possessed)  and  that  the  system  will 
ensure  the  integrity  of  this  information. 

Improvements  in  survivability  means  that  in  the  event 
a  critical  part  of  the  system  is  unavailable,  due  to 
equipment  failure  or  enemy  action,  the  system  will 
continue  to  have  access  to  stored  information  through 
redundancy.  Additionally,  interoperability  between 
the  force  and  unit  levels  will  be  enhanced  by  using  a 
common  infrastructure.  Information,  including  the 
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Air  Tasking  Order  (ATO).  could  be  transmitted 
through  database-to-database  transfers  instead  of  the 
present  methods  of  formatted  messages.  Such 
formatted  messages  would  still  be  needed  for  other 
users.  However,  significant  time  savings  and 
communications  bandwidth  savings  would  accrue. 

A  common  technical  infrastructure  will  mean  less 
software  to  maintain.  Instead  of  maintaining  separate 
^ftware  support  systems,  fewer  lines  of  code  would 
be  fielded  and  significant  life  cycle  savings  would 
result  Significantly  less  software  to  maintain 
translates  into  sizable  life  cycle  cost  savings. 


3.0  IMPLICATIONS  OF  USING 

COMMERCIAL  TECHNOLOGY 

Several  criteria  should  be  investigated  when 
considering  the  use  of  commercial  technology.  Is  the 
time  ripe  to  migrate  from  unique  development  to 
commercial  technology?  Can  all  of  the  system 
requirements/conditions  be  met?  What  is  the  state  of 
commercial  technology,  is  it  migrating  consistent  with 
standards,  and  is  it  a  viable  product  in  the 
maikeq)lace? 

Additionally,  some  analysis  should  be  performed  to 
provide  the  basis  for  sound  engineering  judgment: 
technical  versus  performance  trade  offs,  cost/benefit 
economic  analysis,  and  the  review  of  requirements. 

All  of  these  are  explored  in  greater  detail. 


State  of  Commercial  Technology 
In  addition  to  understanding  the  requirements  of  the 
software  architecture,  the  state  of  commercial 
software  must  be  well  researched,  and  well 
understood,  before  any  determination  can  be  made 
regarding  its  use  for  military  or  commercial 
infrastructures.  As  an  example,  in  1987  when  the  Air 
Operations  Center  (AOC)  portion  of  CTAPS  was 
being  designed  and  implemented,  several  important 
technologies  were  not  commercially  available.  While 
commercial  relational  databases  and  graphical 
windowing  systems  were  available,  commercial 
solutions  for  distributed  computing  systems  and 
distributed  file  systems  were  not.  This  lack  of 
commercial  software  caused  the  government  to  pay 
for  custom  development  to  implement  validated  user 
requirements.  Now,  eight  years  later,  commercial 
solutions  to  these  requirements  are  finding  their  way 
to  the  market  place;  and  into  DOD  C2  AISs. 

The  initial  uses  of  commercial  technology  in  DOD  C2 
systems  have  been  in  the  traditional  areas:  operating 
systems  and  typical  business  applications  (e.g., 
spreadsheets,  relational  databases,  and  word 
processing).  These  are  market  areas  that  found  a 
significant  customer  base  and  reached  maturity 
quickly.  With  the  growth  of  AISs  in  the  commercial 
sector,  and  in  particular  AISs  to  support  larger  multi¬ 
location  corporations,  other  functional  areas  such  as 
network  and  system  management  have  found 
commercial  solutions.  A  review  of  the  infrastructure 
functional  areas  produced  the  following  results: 


Table  1.  Current  State  of  Commercially  Available  Technology 


Infrastructure 

area 

Commercially 

available 

Meets  TBM  C2 
Rqmnts. 

Mature 

tecbnoloey 

Multiple 

vendors 

System  Admin. 

Yes 

Yes  tn 

No 

Yes 

Manning 

Yes 

No 

No 

Yes 

Email 

Yes 

Yes  fl) 

Yes 

Yes 

Alert  Services 

Yes 

Yes 

Yes 

Yes 

Message 

Processing 

No 

No 

Yes 

Yes 

USI  Services 

Yes 

Yes  (1) 

Yes 

Yes 

Granhic  Services 

Yes 

Yes 

Yes 

Yes 

Data  Management 
Services 

Some 

Yes(l) 

Yes  (3) 

Yes 

Data  Interchange 
Services 

No 

No  (2) 

No 

7 

Network  Services 

Yes 

Yes 

Yes 

Yes 

Program  Services 

Some  1 

Yes 

Yes 

Yes 

OS  Services 

Yes 

Yes 

Yes 

Yes 

Note  1:  With  some  customization  of  commercial  product  using  vendor  supplied  tools. 
Note  2:  Unique  DOD  data  formats  discourages  much  commercial  development 
Note  3:  Data  replication  still  appears  to  be  a  young  technology. 
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Table  2.  State  of  Future  Commercially  Available  Technology 


Infrastructure 

area 

Commercially 

available 

Meets  TBM  C2 
Rqmnts. 

Mature 

technology 

Multiple 

vendors 

System  Admin. 

Yes 

Yesd) 

Yes 

Yes 

Mapping 

Yes 

No 

No 

Yes 

Email 

Yes 

Yes 

Yes 

Yes 

Alert  Services 

Yes 

Yes 

Yes 

Yes 

Message 

Processing 

No 

No 

Yes 

Yes 

USI  Services 

Yes 

Yesd) 

Yes 

Yes 

Graphic  Services 

Yes 

Yes 

Yes 

Yes 

Data  Management 
Services 

Some 

Yes 

Yes 

Yes 

Data  Interchange 
Services 

No 

No 

No 

Yes 

Network  Services 

Yes 

Yes 

Yes 

Yes 

Program  Services 

Yes 

Yes 

Yes 

OS  Services 

Yes 

Yes 

Yes 

Yes 

The  COTS  picture  changes  very  rapidly  and  should  be 
continuously  evaluated.  Many  requirements  that 
could  not  be  solved  by  commercial  solutions  as  little 
as  a  year  ago  now  have  viable  commercial  solutions. 

In  some  cases,  the  solution  did  not  exist  at  all;  in  other 
cases,  the  solution  existed  but  could  not  be  used 
because  of  inadequate  performance,  lack  of  sufficient 
functionality,  or  an  inability  to  meet  perceived  user 
environment^  requirements.  With  a  greater  emphasis 
on  commercial  use  of  software  within  the  government, 
more  and  more  infrastructure  areas  are  capable  of 
being  solved  by  commercial  solutions.  Moreover, 
many  new  technologies  like  the  Open  Software 
Foundation's  Distributed  Computing  Environment 
(DCE)  and  the  Object  Management  Group’s  (OMG) 
Common  Object  Request  Broker  Architecture 
(CORE A)  provide  solutions  that  transcend  the 
boundaries  between  infrastructure  areas.  For  example, 
DCE  could  provide  solutions  to  security  and  system 
administration  as  well  as  support  for  distributed 
computing. 

Technologies  like  the  CORE  A,  and  specifications  like 
the  Common  Open  Software  Environment  (COSE), 
and  the  operating  system  interface  SPEC  1170  provide 
even  greater  functionality  and  open  standards  and 
mitigate  some  of  the  risks  of  mixing  commercial 
technology  with  unique  development.  Our 
investigations  indicate  that  additional  capabilities  will 
be  served  by  commercial  solutions  in  the  near  future. 


4.0  MIGRATION  FROM  LEGACY  SYSTEMS 

Several  items  ease  the  migration  of  legacy  systems. 
First  and  foremost  is  an  abstract  definition  of  the 
framework  (i.e.,  software  architecture)  for  the  desired 
infrastructure.  An  abstract  design  allows  the 
government  to  have  a  sense  of  the  desired  solution 


unconstrained  by  the  current  state  of  the  technology. 
With  this  objective  design,  an  understanding  of  the 
current  and  future  trends  in  software  technology,  and 
an  understanding  of  the  functional  requirements  of  the 
current  system,  the  government  can  begin  to  analyze 
the  available  solutions  and  map  out  the  steps  needed 
to  migrate  the  legacy  system.  Depending  on  the  size 
of  the  system  (i.e„  the  number  of  components  to 
migrate),  a  migration  model  can  be  constructed. 

The  government  must  also  have  a  good  understanding 
of  the  state  of  development  of  the  legacy  system.  This 
implies  an  understanding  of  the  maturity  of  the 
software,  its  current  ability  to  meet  the  user’s 
requirements,  how  well  it  was  developed  (e.g., 
complexity,  clarity,  defined  interfaces,  modularity), 
and  how  easy  it  is  to  maintain.  Migration  from 
existing  interfaces  and  services  will  cause  new 
development  in  the  migrated  legacy  components. 
Although  not  exhaustive,  the  following  steps  construct 
the  minimum  migration  model: 

How  -  The  Method 

This  step  is  where  the  government  makes  an 
evaluation  of  the  methods  that  might  be  used  to 
migrate  from  unique  development  to  commercial 
solutions.  This  step  takes  into  account  all  of  the 
information  gained  in  the  survey  of  the  commercial 
marketplace,  what  products  are  becoming  mature,  and 
what  new  products  are  showing  up. 

Once  the  preparatory  work  is  done,  the  government 
must  determine  a  systematic  way  to  bring  commercial 
products  into  C2  information  systems.  This  implies  a 
standardized  methodology  that  might  be  empirically 
defined,  or  might  have  been  used  on  a  previous 
project. 
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The  methodology  must  also  be  able  to  accommodate 
partial  or  total  replacement  of  existing  components, 
depending  on: 

•  the  modularity  of  the  components  in  the  legacy 
system 

•  the  maturity  of  the  components  in  the  legacy 
system 

•  the  availability  of  capable  commercial 
replacements. 

The  most  difficult  part  in  the  migration  is  controlling 
the  potential  ripple  effect  of  replacing  software 
components  in  an  established  system.  The  use  of 
software  reverse  engineering  tools  to  identify  potential 
conflict  areas  will  help  to  lessen,  but  may  not  prevent, 
new  problems  based  on  software  component 
replacement 

When  -  The  Timing 

Determining  when  to  migrate,  or  replace,  unique 
legacy  components  is  the  most  difficult  of  all  the 
migration  steps.  This  is  true  partially  because  there  is 
no  good  source  of  historical  data,  and  partially 
because  there  are  no  good  metrics  for  determining  the 
migration  timing.  It  depends  on  many  criteria,  some 
that  the  program  manager  has  little  control  over  like 
issues  of  commercial  availability,  but  also  others  that 
can  be  understood  and  characterized  with  the  use  of 
tradeoff  analysis  and  studies. 


5.0  MIGRATION  TRADEOFFS 

Technical/Performance  Tradeoffs 
Of  all  of  the  tradeoffs  to  be  considered  during 
migration  planning,  technical/performance  is  one  of 
the  most  difficult.  Although  these  are  the  tradeoffs 
that  system/software  engineers  are  most  comfortable 
with,  issues  of  architectural  complexity  (e.g.,  client/ 
server  design,  application  and  data  distribution, 
distributed  computing)  make  these  tradeoffs  difficult 
Additional  difficulty  in  this  set  of  tradeoffs  comes 
from  not  having  a  clear  understanding  of  the 
functional  requirements  or  the  capabilities  of  the 
vendor’s  products,  or  the  ability  of  the  vendors 
products  to  be  modified  or  tailored  to  meet 
requirements. 

If  the  software  architecture  has  stringent  performance 
requirements,  as  is  often  typical  of  large  AISs, 
whether  military  or  commercial,  a  simulation  of  the 
architecture  may  be  warranted.  This  simulation  can 
provide  insight  into  the  performance  of  the  software 
architecture.  This  simulation  may  be  difficult  to 
assemble  and  run  since  the  actual  performance  values 
of  many  of  the  pieces  of  commercial  software  may  be 
unknown.  In  this  case,  a  series  of  prototypes,  ranging 
from  notional  to  full  capability  may  provide  the  data 
needed  to  validate  the  use  of  commercial  standards 
based  components  in  the  software  architecture. 


Requirements  Review 

It  is  important  to  note  that  the  ability  to  replace  unique 
development  with  commercially  available  technology 
is  not  a  panacea,  nor  is  it  a  replacement  for  a  good 
understanding  of  the  functional  requirements  of  the 
system.  The  increased  availability  of  commercial 
technology  should  eventually  force  a  definition  of  the 
requirements  in  a  broader,  less  rigid  fashion.  Rigidly 
defining  the  requirements  (leaving  little  room  for 
negotiation)  almost  always  causes  unique 
development 

There  will  be  cases  where  a  closer  examination 
(cost/benefits  tradeofO  of  the  requirements  may 
indicate  that  the  vendor’s  commercial  solution  is  not 
capable  of  meeting  the  user's  needs.  However,  in  this 
case,  development  using  vendor  provided  tools,  may 
provide  an  adequate  solution  to  the  requirement  as 
opposed  to  new  custom  development  The  availability 
of  commercial  technology  should  be  used  as  a  metric 
to  justify  examination  of  requirements,  but  it  should 
never  be  used  to  cause  the  capitulation  of  valid 
requirements.  The  cost  of  implementing  a 
requirement  through  unique  development  is 
investigated  through  an  economic  analysis. 

Economic  Tradeoffs 

While  replacing  custom  developed  components  has 
the  potential  to  reduce  future  maintenance  costs,  and 
decrease  overall  system  complexity,  it  often  requires 
investment  from  this  years'  budget  to  gain  perceived 
advantages  in  the  future.  There  is  a  perception  that 
significantly  higher  costs  are  associated  with  the  use 
of  COTS.  An  economic  analysis  performed  for  a 
DOD  C2  AIS  indicated  that  replacement  of  a  custom 
developed  system-support  service  component  with 
COTS,  including  licensing,  was  no  more  expensive 
than  the  custom-developed  application,  even  without 
consideration  to  long-term  maintenance.  This  analysis 
provides  an  example  of  how  the  government  can 
leverage  off  of  the  product  and  domain  expertise  of  a 
commercial  vendor  instead  of  bearing  the  burden  of 
development  and  maintenance  of  custom  applications. 

Leveraging  off  of  the  vendor’s  expertise  does  not 
come  without  its  own  set  of  associated  risks.  By 
accepting  commercial  technology,  the  government 
gives  up  the  right  to  source  code,  and  potentially  to 
data  rights.  Using  commercial  technology  often 
results  in  a  right  to  use  license  rather  than  complete 
and  unchallenged  ownership.  As  long  as  the 
commercial  software  meets  the  stated  requirements,  or 
can  be  extended  using  vendor  provided  tools,  the  lack 
of  source  code,  or  the  right  to  use  license  should  not 
cause  problems. 

Other  issues  arise  with  respect  to  the  difficulties  of 
contracting  for  the  use  of  commercial  technology. 

Even  if  the  contract  can  be  established  with  sufficient 
flexibility  on  the  part  of  the  government,  there  is 
always  a  difficulty  in  the  timing  between  contract 
award  dates  and  COTS  availability  dates. 

Additionally,  the  government  always  has  the  ability  to 
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Figure  2.  Object  Management  Architecture  (OMA) 


direct  the  contractor  to  use  COTS  instead  of  custom 
development,  but  this  is  always  done  with  an 
acceptance  of  risk  on  the  part  of  the  government. 

Another  compounding  factor  regarding  the  use  of 
commercial  technology  is  the  pace  and  volatility  of 
the  commercial  marketplace.  When  considering  a 
commercial  product,  the  size  of  the  corporation  may 
not  be  as  important  a  consideration  as  several  other 
criteria.  For  example,  if  the  corporation  is  a  member 
of  a  consortium  that  specifies  standards  and  practices, 
the  corporation’s  products  may  stand  a  higher  chance 
of  being  widely  accepted  as  a  defacto  industry 
standard.  Additionally,  the  consortiums  also  help  to 
focus  “product  development”  as  a  solution  to  vertical 
markets. 


6.0  EVOLVING  FROM  LEGACY  WITH 
COMMERCIAL  TECHNOLOGY 

The  integration  of  existing  C2  systems  presents  many 
technical  challenges.  The  existing  systems  were 
generally  developed  to  automate  individual  manual 
processes  with  little  concern  for  future  integration.  As 
a  result,  the  integration  effort  must  address  the 
inconsistent  subsystem  interfaces,  inconsistent  use  of 
system  services,  inconsistent  user  interfaces,  and 
duplicative  databases.  Current  approaches  have 
shortfalls.  The  use  of  commercial  technology  in 
military  and  government  systems  is  recognized  as  a 
primary  means  to  reduce  cost  and  time  to  deployment 
The  commercial  world  is  developing  tools  based  on 
open  systems  and  object-oriented  technology  through 
cooperative  organizations  such  as  the  Open  Software 
Foundation  (OSF)  and  OMG. 

Distributed  Object  Management  (DOM)  is  a  key 
underlying  technology  for  enabling  distributed 
processing  in  distributed  heterogeneous  information 
systems.  A  DOM  system  provides  a  means  by  which 
software  components  may  be  instantiated,  accessed, 


coordinated,  and  otherwise  controlled,  independent  of 
the  underlying  platforms.  DOM  systems  make  it 
possible  to  develop  complex  systems  that  are  made  up 
of  legacy  applications  and  new  applications  develop^ 
by  different  organizations,  because  the  application 
interfaces  are  well  defined  and  catalogue  for  easy 
access  and  browsing.  In  addition,  DOM  systems 
provide  a  uniform  set  of  services  (change 
management,  naming,  transactions,  security,  query, 
backup,  replication,  etc.)  that  can  be  used  by  any 
application. 

OMG 

The  OMG  is  a  consortium  of  over  400  companies, 
including  vendors  such  as  Sun,  Hewlett-Packard, 

IBM,  Microsoft,  Apple,  Digital  Equipment 
Corporation  (DEC)  and  database  management  system 
developers  such  as  Oracle,  Sybase,  and  Object 
Design.  The  members  of  OMG  [OMAG  92]  have  “a 
shared  goal  of  developing  and  using  integrated 
software  systems.”  TTie  mission  of  OMG  is  to 
develop  “a  set  of  standard  interfaces  for  interoperable 
software  components.”  OMG  is  developing  a 
standard  for  object-oriented  middleware  that  realizes 
interoperability  among  independently  developed 
applications  across  networks  of  heterogeneous 
computers  by  defining  the  Object  Management 
Architecture  (OMA),  an  architectural  framework  with 
supporting  detailed  interface  specifications  (Figure  2). 

Department  of  Defense  InteUigence  Information 
Systems  pODHS)  and  DOD  TAFIM  Profiles 
In  our  opinion,  the  CORE  A,  Common  Object  Support 
Software  (COSS),  and  Common  Object  File  System 
(COFS)  specifications  appear  to  supplement  the 
DODIIS  Client-Server  Environment  (CSE)  [Sure94] 
and  the  DOD  TAFIM  profiles.  The  CSE  and  TAFIM 
profiles  specify  a  collection  of  guidelines,  data 
formats,  APIs,  protocols,  and  COTS  application 
programs.  CORE  A  might  be  considered  to  replace 
the  networking  components  of  these  profiles. 
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Table  3a.  DOM  Products 


DEC 

HP 

Sun 

OpenVMS 

OSF/1 

Ultrix 

HP-UX 

Solaris 

SunOS 

IBM  SOM/DSOM 

— 

— 

— 

95 

— 

— 

HyperDesk  (withdrawn) 

— 

— 

— 

93 

— 

93 

Digital  ACAS  (replaced) 

93 

93 

93 

93 

— 

93 

Digital  ObjectBroker 

94 

94 

94 

94 

— 

94 

HP  Distributed  SmallTalk 

— 

— 

— 

now 

now 

now 

HP  ORB  Plus 

— 

— 

— 

95 

— 

— 

IONA  Orbix 

— 

94 

now 

now 

now 

now 

Sun  DOE  +  OpenStep 

— 

— 

— 

— 

95 

— 

Table  3b.  DOM  Products 


IBM 

Apple 

Microsoft 

AIX 

MVS 

OS/400 

OS/2 

MacOS 

NT 

Windows 

IBM  SOM/DSOM 

now 

94 

95 

now 

— 

now 

now 

HyperDesk  (withdrawn) 

93 

— 

— 

— 

— 

— 

93 

Digital  ACAS  (replaced) 

93 

— 

— 

— 

93 

93 

93 

Digital  ObjectBroker 

94 

— 

— 

— 

94 

94 

94 

HP  Distributed  SmallTalk 

now 

— 

— 

now 

now 

now 

now 

HP  ORB  Plus 

— 

— 

— 

— 

— 

— 

— 

IONA  Orbix 

94 

— 

— 

94 

— 

now 

94 

Sun  DOE  +  OpenStep 

— 

— 

— 

— 

— 

— 

— 

Standard  user  interface  objects  can  be  developed 
using  CORE  A  that  would  help  enforce  a  style  guide 
“look  and  feel”  to  applications.  COREA  wrappers 
provide  interoperability  among  application  service 
components  in  a  uniform  manner.  The  DODIIS 
CSE  intends  to  follow  the  COREA,  COSS,  and 
COFS  specifications  as  they  continue  to  evolve  with 
a  view  toward  inclusion  of  these  specifications  in 
future  releases  of  its  profiles. 

Other  DOM  Products 

Tables  3a  and  3b  show  the  major  vendors’  rollout 
plans  for  object  technology.  The  vendors 
themselves  were  the  source  of  all  of  the  information 
supplied  in  the  table.  Some  of  the  information  was 
taken  from  Open  Systems  Today,  August  1, 1994, 
page  69.  The  “ — ”  in  the  tables  indicates  that  the 
implementation  is  not  planned  at  the  present  time; 
“94”  means  it  is  planned  for  late  1994/early  1995. 

In  addition  to  the  these  products,  Taligent  and  Apple 
plan  to  use  lEM’s  DSOM.  Microsoft  and  DigitaJ  are 
developing  a  Common  Object  Model  (COM) 
specification  that  is  similar  to  COREA  in  many 
ways.  DEC  plans  to  provide  a  gateway  between 
ObjectEroker  objects  and  COM  objects. 

The  Use  of  CORE  A  Products,  A  1995  Perspective 
DOM  technology’s  greatest  strength  is  that  it  can 
provide  interoperability  among  mission  applications. 


support  applications,  and  distributed  services.  It  can 
be  used  to  wrap  data  formats,  APIs,  application 
programs,  and  enforce  guidelines  and  protocols.  Old 
stovepipe  applications  can  be  encapsulated  with 
relatively  little  effort  so  that  they  can  continue  to  be 
used  in  *e  evolving  system  until  they  can  be 
modernized  or  replaced. 

DOM  technology  provides  a  means  to  support  the 
development  of  evolvable  systems.  An  evolvable 
system  changes  over  time  to  exploit  more  powerful 
hardware  and  to  address  new  user  requirements 
which  necessitate:  the  incorporation  of  new 
applications  (mission  or  COTS),  the  incorporation  of 
new  databases  (information  sources),  or  the 
modification  of  existing  applications  and/or  database 
organization  (structure  or  schema).  An  evolvable 
system  is  generally  complex  involving 
heterogeneous  hardware  (both  different  vendors  and 
different  generations)  and  heterogeneous  user 
communities  (users  using  the  same  applications/ 
databases  may  have  different  tasks  to  perform  and/or 
different  levels  of  training). 

We  believe  DOM  technology  holds  great  promise, 
however,  it  must  be  said  that  from  an  early  1995 
perspective,  it  is  still  too  immature  to  be  used  in 
mission  critical  systems.  OMG  specifications 
(COREA/COSS/COFS)  are  immature.  The  COREA 
1.2  specification  did  not  enforce  interoperability 
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among  DOM  vendors;  however,  in  early  1995, 
agreement  for  the  CORBA  2.0  has  been  reached  that 
specifies  how  DOMS  should  interoperate. 

However,  there  have  been  a  number  of  early 
agreements  among  UNDC  vendors  to  develop  DOM 
environments  that  are  capable  of  interoperating. 

{For  example.  Candle,  HP,  and  IBM  demonstrated 
interoperaWe  products  at  Object  World  San 
Francisco  in  July  1994,  as  did  Fujitsu,  IONA,  Post 
Modem  Computing,  and  SunSoft,  and  Digital 
demonstrated  access  to  their  products  from 
Microsoft  Windows  applications  via  OLE  2.0.) 

By  late  1995,  we  can  expect  that  there  will  be  many 
CORB A-compliant  commercial  products  available. 
Many  object  services  specifications  should  be  agreed 
on  and  several  should  be  available  in  DOM  products. 
There  should  be  some  off-the-shelf  applications  and 
many  encapsulated  legacy  applications  available. 
There  may  be  some  support  for  soft  real-time 
processing  to  support  multimedia.  By  1995,  the 
government  should  have  an  acquisition  strategy  in 
place  for  information  systems.  Hardware  platforms 
that  are  capable  of  running  CORB  A-compliant 
DOMs  should  be  required.  Application  developers 
should  be  required  to  develop  CORB  A-compliant 
Interface  Definition  Language  (IDL)  interfaces  to 
their  applications.  Further,  application  developers 
should  be  required  to  anticipate  the  availability  of 
object  services  and  facilities-either  to  make  use  of 
interfaces  for  already  specified  object  services/ 
facilities  or  to  encapsulate  the  services/facilities  they 
develop  so  that  they  can  be  replaced  easily  when 
appropriate  object  services/facilities  are  available. 

By  1997,  CORBA  vendor  products  should  be 
interoperable.  Many  object  services  should  be 
specified  and  available.  Many  off-the-shelf 
applications  should  exist.  DOM  vendors  should  be 
able  to  support  some  real-time  processing,  at  least  as 
far  as  supporting  multimedia  applications.  Although 
this  level  of  support  may  not  be  adequate  for 
supporting  the  hard  real-time  applications  required 
by  the  military,  it  may  be  possible  to  support  soft 
r^-time  military  applications. 


7.0  CURRENT  INVESTIGATIONS 
DOM 

Investigations  at  The  MITRE  Corporation  are 
examining  issues  in  migrating  legacy  C2  systems 
using  DOM  technology  as  an  integration  framework. 
In  particular,  the  project  is  using  a  commercial  DOM 
system  to  integrate  subsystems  in  the  Air  Force’s 
CTAPS  system  of  systems. 

The  technical  objective  of  the  MITRE  DOMIS 
project  is  to  identify  approaches  for  integrating 
legacy  systems.  We  believe  that  OMG-compliant 
DOM  technology  can  be  used  to  provide  an 
integration  framework.  To  test  our  hypothesis,  we 
are  conducting  a  set  of  experiments.  Important 


aspects  of  these  experiments  are  the  ease  of  coarsely 
encapsulating  legacy  applications  and  databases,  the 
ease  of  refining  this  coarse  encapsulation  to  provide 
a  better  integration  of  the  legacy  applications  and 
databases,  the  applicability  of  the  OMG  object 
services  to  C3I  systems,  the  identification  of 
techniques  for  integrating  databases  that  use 
different  database  management  systems  (for 
example,  Sybase  for  intelligence  and  Oracle  for  C2) 
within  the  DOM  environment,  and  the  identification 
of  techniques  for  integrating  heterogeneous 
applications  and  databases  with  respect  to  data 
naming.  Our  technical  objective  also  includes 
influencing  vendors  through  our  participation  in 
OMG  and  recommending  an  acquisition  approach 
based  on  a  DOM  system  as  an  integration 
framework. 

Improved  System  Administration  (ISA) 
Additional  investigations  are  underway  prototyping 
an  ISA  function.  This  ISA,  based  on  commercial 
software,  is  eventually  intended  to  provide  a 
replacement  for  a  uniquely  developed  system 
achninistration  application.  Using  commercial 
software  embracing  open  standards,  an  ISA  is  being 
prototyped  at  MITRE  for  the  WCCS  System  using 
the  commercial  product  Tivoli.  Although  this  effort 
has  been  recently  initiated  in  January  1995,  we 
expect  to  witness  improvements  to  end-user  ease  of 
use  and  to  provide  for  a  homogeneous  system 
administration  environment  (e.g.,  user  access, 
privileges,  passwords,  network,  account,  and 
security  administration). 


8.0  CONCLUSIONS 

Increases  in  commercial  technology  will  necessarily 
provide  the  potential  to  change  many  facets  of  C2 
AISs.  These  increases  have  the  potential  to  impact 
business  practices,  the  operations  (i.e.,  doctrine  of 
C2  AISs),  as  well  as  the  system  architecture  (i.e., 
hardware  and  software).  A  wider  availability  of 
commercial  desktop  computers  with  accompanying 
desktop  application  software  has  opened  a  new,  and 
currently  separate,  world  to  many  of  the  users  of  C2 
AISs.  The  ability  of  desktop  users  to  easily  access 
and  reuse  information  derived  from  commercial  and 
military  global  sources  (e.g.,  commercial  data 
providers.  Prodigy,  America  On  Line)  will  create  a 
need  to  provide  this  same  capability  in  C2  AISs. 

Providing  global  reuse  and  manipulation  of  data 
within  C2  AISs  presents  several  difficulties  for  the 
system  designers  and  implementers.  Discounting  the 
obvious  issues  of  data  security  and  integrity,  several 
issues  involving  the  use  of  a  desktop  paradigm  (e.g., 
distributed  versus  localized  computing,  complex 
relational  data  storage  versus  single  element/single 
file  storage)  in  C2  AISs  must  be  resolved. 
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In  order  to  prepare  for  the  eventual  changes,  the 
government  must  get  abreast  and  stay  abreast  of 
changes  in  the  commercial  marketplace. 
Additionally,  the  government  should  support 
continued  investment  in  migration  and  legacy 
techniques: 

•  software  reverse  engineering  to  identify  software 
component  dependencies 

•  migration  of  software  components  to  emerging 
open  technologies 

•  encapsulation  of  legacy  components  utilizing 
DOM  technology  to  allow  their  reuse  until 
replacement 

Finally,  the  government  should  work  at  developing 
new  cost  models,  including  resourcing,  scheduling, 
and  commercial  availability  modules,  which  would 
give  the  program  managers  additional  tools  to  aid  in 
their  migration  planning. 
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SIMULATION  MODELS  FOR  IFF  SYSTEM  PERFORMANCE  ANALYSIS 
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SUMMARY 

Identification  Friend  or  Foe  (IFF)  is  an  important  means  of 
air  traffic  surveillance  for  military  air  operation.  Due  to  this 
fact,  several  studies  of  IFF  equipment  were  conducted  in  the 
past.  To  assist  the  analysis  of  IFF  system  performance,  two 
simulation  models  have  been  developed  at  "ESG 
Elektroniksystem-  und  Logistik  GmbH"  in  Munich, 
Germany.  The  description  of  these  models  is  the  main 
subject  of  this  paper. 

The  first  model  is  based  on  a  probabilistic  methodology.  It 
operates  on  a  scenario  reflecting  the  environment  to  be 
considered.  The  model  determines  the  interrogation  rates  at 
each  transponder  deployed  in  the  environment.  Applying 
probability  theory,  the  behaviour  of  the  transponders  is 
predicted  and  their  reply  rates  are  obtained.  The  reply  rates 
are  the  input  for  the  calculation  of  the  signal  loads  at  the 
interrogators  and  the  establishment  of  their  behaviour. 

The  second  model  is  designed  as  a  discrete-event  simulation 
model.  At  each  point  in  time  an  interrogation  is  generated, 
the  arrival  times  and  the  power  levels  of  the  interrogation  at 
the  transponders  are  determined.  The  processing  of  the 
interrogation  by  the  transponders  is  modelled  taking  into 
account  various  interference  mechanisms.  If  a  reply  is 
challenged  by  an  interrogation,  the  arrival  times  and  the 
signal  power  levels  at  the  interrogators  are  calculated. 
Interferences  with  the  reply  are  checked  in  order  to  establish 
the  proper  evaluation  of  the  signal  by  the  interrogator. 

1.  INTRODUCTION 

IFF  systems  are  utilised  to  identify  friendly  airborne 
platforms,  IFF  systems  consist  of  interrogators  and 
transponders.  Interactions  between  these  components  are 
performed  on  the  principle  of  question  and  answer.  A 
question  is  generated  by  the  interrogator  as  a  coded 
electromagnetic  signal  and  transmitted  towards  an  airborne 
platform.  An  aircraft  equipped  with  a  transponder  decodes 
the  question  and  transmits  a  coded  reply  as  a  response. 
Finally,  the  reply  is  received  and  evaluated  by  the 
interrogator  to  obtain  the  identity  of  the  aircraft. 

The  first  IFF  system  was  introduced  in  1948.  The  system 
called  MKX  employed  the  interrogation  frequency  1030 
MHz  and  the  reply  frequency  1090  MHz.  Three  different 
coded  interrogations  were  implemented,  designated  as  Mode 
1,  Mode  2,  and  Mode  3,  while  only  one  unique  reply  signal 
was  defined  consisting  of  four  pulses.  All  signals  were  pulse 
position  modulated. 

During  the  following  years,  the  MKX  system  was  improved 
by  introducing  a  coder-unit  within  the  transponder,  which 
was  able  to  provide  additional  reply  information  by 


generating  variable  coded  replies.  This  coding  capability  was 
termed  "Selective  Identification  Feature"  (SIF).  Therefore, 
the  improved  MKX  system  was  named  MKX(SIF), 

Currently  in  use  is  the  successor  of  the  MKX(SIF)  system, 
which  is  termed  MKXA.  The  interrogation  and  reply  signals 
of  the  MKXA  system  are  pulse  position  modulated  on  a  1030 
MHz  (interrogation)  and  1090  MHz  (reply)  carrier 
frequency.  MKXA  utilises  the  interrogation  Modes  1,  2,  3/A, 
and  C.  For  each  of  the  Modes  1,  2,  and  3/A,  4096  reply 
codes  are  available,  which  can  provide  identity  information 
of  an  aircraft.  Mode  C  is  used  for  altitude  reporting. 

In  order  to  increase  the  resistance  of  IFF  against  spoofing, 
exploitation,  and  jamming,  a  new  cryptographic  encoded 
feature  designated  as  Mode  4  was  added  to  the  MKXA 
system  during  the  1960's.  The  resulting  IFF,  containing 
Mode  1,  Mode  2  ,  Mode  3/A,  Mode  C,  and  Mode  4,  has  been 
called  MKXn. 

At  the  beginning  of  the  1980's,  a  common  process  has  been 
initiated  by  different  nations  to  define  a  NATO  wide 
compatible  IFF  system  based  on  modern  technologies.  The 
concepts  for  this  future  IFF  system  are  termed  NIS  (Nato 
Identification  System)  and  NGIFF  (Next  Generation  IFF), 

Because  of  the  dependency  on  IFF  for  air  traffic  control  and 
engagement  purposes,  several  studies  of  contemporary  IFF 
equipment  (MKXA,  MKXII)  as  well  as  future  military 
identification  systems  (NIS,  NGIFF)  were  conducted.  The 
overall  objective  of  these  investigations  was  to  establish  a 
realistic  basis  for  the  assessment  of  the  IFF  system 
performance  in  dense  environments. 

Two  simulation  models  for  IFF  system  performance  analysis 
are  introduced  in  this  paper.  The  models  quantify  the 
interference  impacts  at  transponders  and  interrogators 
deployed  in  an  environment  and  predict  their  behaviour. 
Although  both  models  are  suitable  for  IFF  analysis,  they 
differ  with  respect  to  the  modelling  philosophy.  The  first 
model  is  based  on  a  probabilistic  method  applying  statistical 
principles,  the  second  consists  of  a  discrete-event  simulation 
program  modelling  the  different  occurrences  within  an  IFF 
system.  The  description  of  these  models  is  the  main  subject 
of  this  paper. 

The  paper  is  structured  into  7  parts.  Following  this 
introductory  section,  section  2  contains  a  brief  description  of 
the  main  features  of  IFF  systems.  Section  3  discusses  the 
environment  model,  which  serves  as  input  for  the  simulation 
programs.  Tlie  probabilistic  simulation  model  and  the 
discrete-event  model  are  described  in  section  4  and  5. 
Outputs  of  the  models  as  well  as  conclusions  and  final 
remarks  are  the  content  of  section  6  and  7. 


Paper  presented  at  the  AGARD  MSP  3rd  Symposium  on  “Tactical  Aerospace  C^I  in  Coming  Years”, 
held  in  Lisbon,  Portugal  from  15th  May  to  18th  May  1995,  and  published  in  CP-557. 
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2,  IFF  SYSTEM  DESCRIPTION 

2.1  Generation  of  Interrogations 

For  transmission  purposes  an  IFF  interrogator  is  equipped 
with  an  antenna  system  consisting  of  a  directional  and  a 
control  antenna.  The  directional  antenna  is  characterised  by  a 
main  beam  with  high  antenna  gain  and  series  of  side  lobes 
with  lower  gains.  The  control  antenna  is  designed  as  an 
omni-directional  pattern  such  that  its  gain  is  smaller  than  the 
main  beam  gain  and  greater  than  the  major  side  lobe  gain  of 
the  directional  antenna. 

An  interrogator  is  triggered  to  generate  interrogations 
periodically  at  a  defined  interrogation  repetition  frequency. 
The  final  decision,  whether  an  interrogation  is  initiated,  is 
controlled  by  the  interrogation  protocol.  The  current  IFF 
systems  MKXA  and  MKXII  are  using  the  protocol  types 
continuous,  automatic,  autospecific,  and  manual.  The 
respective  definitions  of  these  protocol  types  are  as  follows. 

An  interrogator  utilising  continuous  protocol  generates 
interrogations  permanently  independent  of  the  presence  of 
targets. 

An  interrogator  operated  with  automatic  protocol  initiates 
interrogations  each  time  a  target  is  detected  by  the  associated 
primary  radar  -  irrespectively  whether  that  target  has  been 
previously  identified.  The  interrogation  process  is  induced 
while  the  antenna  main  beam  is  sweeping  across  the  target. 
During  the  sweep,  a  sequence  of  question  and  answer  cycles 
is  initiated,  which  is  referred  to  as  a  burst. 

Interrogators  using  autospecific  protocol  initiate  an 
interrogation  burst  only  for  a  target  for  which  a  recognised 
track  is  not  held.  Reinterrogation  only  occurs  on  track 
discontinuity. 

An  interrogator  operated  with  manual  protocol  generates 
interrogations  only  when  they  are  initiated  by  an  operator. 

When  an  interrogation  has  been  generated  by  an  interrogator, 
the  signal  is  transmitted  via  the  directional  antenna.  Beside 
the  basic  interrogation,  an  IFF  interrogator  transmits  an 
additional  pulse  via  the  control  pattern,  which  is  called 
Interrogation  Side  Lobe  Suppression  pulse  (IS LS -pulse).  A 
transponder  illuminated  by  the  main  beam  receives  the  ISLS- 
pulse  with  a  power  below  the  interrogation  transmitted  via 
the  directional  antenna.  In  this  case  the  transponder  is  said  to 
receive  a  main  beam  interrogation.  For  a  transponder  located 
outside  the  main  beam,  the  power  of  the  ISLS -pulse  is 
greater  than  the  power  of  the  basic  interrogation.  Therefore, 
the  interrogation  is  termed  a  side  lobe  interrogation. 

2.2  Processing  of  interrogations 

An  interrogation  is  received  by  a  transponder  via  an  omni¬ 
directional  antenna.  Various  techniques  like  diversity  and 
lobe  switching  are  applied  in  order  to  achieve  omni¬ 
directional  antenna  chai‘acteristics  at  an  aircraft. 

When  an  interrogation  enters  a  transponder,  the  transponder 
starts  to  perform  a  set  of  procedures  consisting  of  message 
recognition,  processing,  reply  transmission,  and  recovery. 
The  duration  of  these  procedures  depends  on  the  transponder 
design. 


An  interrogation  can  only  gain  control  of  a  transponder  after 
the  signal  has  been  received  successfully  and  recognised  as  a 
valid  message.  If  the  receipt  of  an  interrogation  interferes 
with  the  arrival  of  another  signal  such  that  they  overlap,  the 
interrogation  may  fail. 

Once  a  valid  interrogation  has  been  obtained,  the  transponder 
enters  the  processing  stage.  The  processing  performs  two 
main  functions.  The  first  function  decodes  the  interrogation 
and  determines  whether  it  is  a  main  beam  or  a  side  lobe 
interrogation. 

If  a  main  beam  interrogation  has  been  recognised,  the 
second  function  is  invoked,  which  produces  a  coded  reply. 
At  the  end  of  the  processing  stage,  the  reply  is  transmitted 
via  the  omni-directional  antenna  of  the  aircraft.  The  reply 
transmission  is  followed  by  a  time  period  which  allows  the 
transmitter  to  recover.  From  the  beginning  of  the  processing 
stage  until  the  end  of  recovery,  the  transponder  is 
suppressed.  Each  interrogation  arriving  during  the 
suppression  time  is  rejected  and  fails. 

When  a  side  lobe  interrogation  has  been  received,  the 
transponder  transmits  no  reply  but  falls  also  into  suppression 
and  does  not  accept  any  interrogation  until  the  end  of 
suppression. 

2.3  Evaluation  of  Replies 

An  interrogator  receives  the  replies  created  in  response  to  its 
own  challenges  via  the  main  beam  of  the  directional  antenna. 
Friendly  Replies  Unsynchronised  In  Time  (FRUIT),  which 
are  replies  from  transponders  elicited  by  other  interrogators, 
may  cause  failure  in  correctly  decoding  an  expected  reply. 

To  reduce  the  impact  by  FRUIT,  interrogators  are  equipped 
with  a  receiver  side  lobe  suppression  (RSLS).  The  receiver 
side  lobe  suppression  is  realised  by  applying  on  the  receiving 
path  a  sum  and  a  difference  channel  simultaneously.  In 
general,  the  sum  channel  is  connected  with  the  directional 
antenna  and  the  difference  channel  with  the  control  antenna. 
The  power  levels  of  a  reply  received  via  both  antennas  are 
compared.  If  the  sum  channel  produces  a  larger  signal 
strength  than  the  difference  channel,  the  reply  is  accepted  as 
a  main  beam  reply.  In  the  other  case,  the  reply  is  designated 
as  a  side  lobe  signal  and  is  ignored. 

Based  on  the  number  of  valid  replies  received  from  a 
transponder,  the  inteiTogator  performs  an  evaluation  process 
and  displays  the  result  on  a  plain  position  indicator  (PPI). 

3.  ENVIRONMENT  MODEL 

The  success  of  an  interrogation-reply  interaction  between  an 
interrogator  and  a  transponder  depends  very  heavily  on  the 
environment  the  IFF  equipment  is  deployed  in.  Therefore,  an 
IFF  simulation  program  requires  as  an  input  an  appropriate 
environment  model,  which  reflects  the  density  and  the 
technical  characteristics  of  interrogators  and  transponders. 
Such  an  environmental  model  is  called  a  scenario, 

A  scenario  is  described  by  parameters,  which  can  be  broken 
down  into  the  following  classes: 

•  platform  data  ( latitude,  longitude,  height,  etc.), 

•  antenna  data  (antenna  geometry,  gains,  etc.), 

•  transmitter-receiver  data  (frequency,  transmitter  power, 
sensitivity,  etc.). 


•  signal  generator  data  (modes,  interrogation  repetition 
frequency,  etc.), 

•  prime  sensor  data  (range,  protocol  type,  etc.),  and 

•  processor  data  (occupancy  and  processing  times). 

For  the  application  of  the  two  simulation  models  described 
in  the  following  sections,  these  parameters  have  to  be 
provided  within  separate  files,  each  containing  data  records 
of  a  specific  parameter  class. 

The  establishment  of  a  simulation  environment  is  realised  by 
a  control  file.  The  control  file  contains  a  list  of  those 
platforms  which  have  to  be  considered  in  a  simulation  run. 
Technical  data  sets  stored  in  the  scenario  files  are  assigned 
to  each  platform  by  reference  numbers.  This  approach,  as 
seen  in  Figure  1,  provides  a  high  degree  of  flexibility 
concerning  the  definition  of  a  simulation  environment. 

4  PROBABILISTIC  MODEL 

The  simulation  model  introduced  within  this  section  was 
developed  originally  for  the  NIS  program.  During  the  late 
1980’s  the  model  was  also  used  for  the  performance  analysis 
of  contemporary  MKXA  and  MKXII  equipment  within  the 
"Central  European  Study"  conducted  by  NATO 
AC/302(SG/5)WG/4.  In  1992  the  model  was  upgraded  to 
include  the  characteristics  of  NGIFF  Mode  7  and  Mode  8 
and  simulation  runs  were  performed  to  support  system 
performance  analysis  and  investigations  concerning 
frequency  compatibility  aspects. 

The  model  is  based  on  a  probabilistic  approach  and  can  be 
functionally  broken  down  into  four  parts: 

•  determination  of  interrogation  rates, 

•  determination  of  transponder  behaviour, 

•  determination  of  fruit  rates,  and 

•  determination  of  interrogator  behaviour. 

Within  the  following  paragraphs  these  parts  are  described 
with  special  emphasis  on  the  mathematical  concepts  applied 
within  each  step. 

4.1  Determination  of  interrogation  rates 
Generally,  the  interrogation  rate  at  a  transponder  is 
established  by  counting  the  arriving  interrogations  during  a 
period  of  time  and  computing  the  ratio  of  the  number  of 
interrogations  and  the  recording  time.  As  the  monitoring 
time  increases,  the  interrogation  rate  gets  into  a  steady  state 
termed  long-term  interrogation  rate. 

In  the  simulation  model  the  extent  of  interrogations  at  a 
transponder  is  characterised  by  the  long-term  interrogation 
rate.  The  model  computes  the  long-term  rates  at  all 
transponders  deployed  in  the  environment.  Due  to  the  ISLS- 
pulse,  an  interrogation  is  received  by  a  transponder  either  as 
a  main  beam  or  as  a  side  lobe  interrogation.  The  time  a 
transponder  is  occupied  by  a  main  beam  interrogation  differs 
from  the  occupancy  time  caused  by  a  side  lobe  signal. 
Therefore,  main  beam  and  side  lobe  interrogations  are 
recorded  separately  by  the  model. 

At  a  particular  transponder  the  interrogation  rate  is 
established  in  two  steps.  Firstly,  the  contribution  from  each 
interrogator  is  computed.  Secondly,  the  total  rate  at  the 
transponder  is  obtained.  In  order  to  shorten  the  description  of 
these  two  steps,  the  following  discussion  will  concentrate  on 


main  beam  rates,  but  it  should  be  noted  that  a  similar 
approach  is  applied  to  the  side  lobe  rate  calculation. 

The  computation  of  the  main  beam  interrogation  rate 
produced  by  a  single  interrogator  /  at  a  transponder  T  is 
based  on  the  following  approach.  Consider  the  events 

A  :  r  is  illuminated  by  the  main  beam  of  /  and 
5  :  /  is  active. 

If  IRF  denotes  the  interrogation  repetition  frequency  of  /, 
the  main  beam  interrogation  rate  MBIR  produced  by  /  at  T 
can  be  calculated  by 

MBIR  =  P(A  n B)  ■  IRF  =  P{A)  P(B/A)‘  IRF. 

Thereby,  P(A)  denotes  the  probability  that  T  is  illuminated 
by  the  main  beam  of  I  and  P(B  f  A)  terms  the  probability 
that  I  is  active  while  T  is  in  the  main  beam  of  I.  Since  the 
activity  of  an  interrogator  depends  on  the  protocol  type,  the 
conditional  probability  P{B  I  A)  is  called  protocol  factor. 

The  calculation  of  P(A)  for  fixed  and  rotating  antennas  is 
very  simple.  In  case  of  a  fixed  antenna  P(A)  =  1,  if  the 
azimuth  angle  from  /  to  T  is  covered  by  the  main  beam, 
otherwise  F(A)  =  0.  If  the  interrogator  is  equipped  with  a 
rotating  antenna,  then 

MBW 
P(A)  =  ^^^, 

2n 

applies,  where  MBVF denotes  the  antenna  main  beam  width. 
Similarly  in  the  case  of  a  scanning  antenna,  the  calculation 
of  P{A)  is  performed  taking  into  account  the  size  of  the 
scanning  sector,  its  orientation,  and  the  azimuth  angle  from 
the  interrogator  to  the  transponder. 

Concerning  the  calculation  of  the  protocol  factor,  by 
definition 

P{B/A)  =  l 

for  continuous  interrogators,  which  are  active  all  the  time. 

An  automatic  interrogator  becomes  active,  if  a  target 
detected  by  the  associated  primary  sensor  enters  the  main 
beam.  The  interrogator  stops  interrogating  as  soon  as  the 
target  leaves  the  main  beam.  Ignoring  the  horrendous 
problem  of  building  the  primary  sensor  target  detection 
performance  into  the  model,  the  assumption  is  made  that 
each  target  within  the  nominal  range  and  height  envelope  of 
the  primary  radar  will  be  detected.  Based  on  this  assumption, 
the  number  of  targets  is  determined  by  the  model  and  a 
function  /  of  the  pointing  angle  a  e  [O,  2k]  of  the  antenna 
boresight  defined  by 

{1,  if  at  least  one  target  is  in  the  beam 
0,  else 

is  established. 

At  any  time  t  g[0,TMLD],  where  TMLD  denotes  the 
duration  the  transponder  T  is  illuminated  by  the  main  beam 
of  I,  the  event 

B{t):  I  ist  active  at  t 

occurs,  if  a  target  detected  by  the  prime  sensor  is  within  the 
main  beam  of  /.  It  should  be  noted  that  the  transponder  T  is 
not  necessarily  a  primary  target,  since  the  IFF  coverage  may 
exceed  the  range  of  the  primary  sensor. 

At  time  t  e  [0,TMLD]  the  antenna  boresight  is  pointing  to 
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,  ,  MBW  MBW 

^  2  TMLD 

where  a  denotes  the  azimuth  angle  fonn  lioT  and  MBW  \hc 
main  beam  width.  By  definition,  the  probability  P{B{t))  that 
I  is  active  at  time  t  satisfies  the  equation 

P{B{t))^f{g(t)) 


for  each  t  e[0JMLD\.  Applying  this  equation  and  utilising 
the  substitution  y  =  g{t)  yields 


P{BIA)  = 


1 

TMLD 


TMLD 

J  P{B{t))dt  =  - 
0 


1 

MBW 

a+ 


2 

Based  on  the  function  /  ,  the  last  integral  is  evaluated  by  the 
model  to  obtain  the  main  beam  protocol  factor  for  a 
automatic  interrogator.  A  similar  approach  is  applied 
concerning  the  protocol  factor  computation  of  autospecific 
and  manual  interrogators. 


So  far  the  calculation  of  the  interrogation  rate  contribution 
from  a  single  interrogator  to  a  particular  transponder  has 
been  discussed.  The  total  interrogation  rate  at  the 
transponder  produced  by  all  interrogators  is  obtained  simply 
by  summing  up  the  individual  contributions. 

In  addition  to  the  interrogation  rates,  the  model  deteimines 
the  power  levels  of  the  signals  at  the  transponders  taking  into 
account  transmitter  power  of  the  interrogator,  cable  losses  on 
the  transmitting  and  the  receiving  path,  transmitter  and 
receiver  antenna  gains,  and  propagation  losses. 


4.2  Determination  of  transponder  behaviour 

The  model  characterises  the  transponder  behaviour  by  the 
parameters  reply  efficiency  (RE)  and  reply  rate  (RR).  The 
reply  efficiency  denotes  the  probability  that  an  interrogation 
is  received,  processed,  and  replied  by  a  transponder.  The 
reply  rate  qualifies  the  average  number  of  replies  transmitted 
by  a  transponder  per  second. 

The  simulation  model  deteimines  reply  efficiency  and  reply 
rate  of  each  transponder  deployed  in  the  scenario  based  on 
the  following  mathematical  methodology. 

Consider  a  transponder  T  exposed  to  a  main  beam 
interrogation  rate  of  MBIR  interrogations  per  second. 
Furtheimore,  assume  that  at  any  time  t  an  interrogation 
anives  at  T.  This  interrogation  is  received,  processed,  and 
replied,  if  the  transponder  is  not  occupied  by  one  of  the 
MB//?  interrogations  at  the  an'ival  time  t  . 

The  total  occupancy  time  Toe  caused  by  an  inteiTogation  is 
defined  as 

Toe  —  Tree  +  Tpre  +  Trep  +  TVev’ , 

where  Tree  is  the  time  required  for  the  receipt  of  the  signal, 
Tpre  the  processing  time,  Trep  the  time  of  reply  transmission, 
and  Trev  the  transmitter  recovery  time.  Taking  into  account 
the  occupancy  time,  the  transponder  is  not  occupied  at  time 
t  ,  if  within  the  interval 

AT  =  [t-Toe,t] 

none  of  the  MBIR  intenogations  arrives.  The  probability  for 
an  arrival  within  AT  is  given  by 


Assuming  that  the  probability  of  k  arrivals  (0  <  ^  <  MBIR) 
obeys  a  binomial  distribution,  the  probability  for  no  arrival 
within  AT  can  be  derived  from 

MBIR  f  MB  IRA 

=  I  (-iW  ^  y^l-MBIR^p. 

Since  p«l,  the  last  equation  is  obtained  by  truncating  all 
terms  of  higher  order  with  respect  to  p . 

If  a  side  lobe  rate  is  received  by  the  transponder  in  addition 
to  the  main  beam  interrogation  rate,  the  same  approach 
yields  the  probability  Psl{0)  for  an  interrogation  being  not 
affected  by  a  side  lobe  signal. 

Combining  the  probabilities  for  main  beam  and  side  lobe 
impact,  the  model  determines  the  reply  efficiency  by 

RE=Pmb(0)-Psl{0). 

The  reply  rate  of  a  transponder,  which  is  an  essential  input 
for  the  determination  of  fruit  rates  at  an  interrogator,  is 
derived  from  the  equation 

RR=MBIRRE. 


4.3  Determination  of  fruit  rates 

An  identification  process,  in  which  an  interrogator  and  a 
transponder  is  involved,  takes  place  during  the  sweep  of  the 
interrogator's  main  beam  across  the  transponder.  Replies, 
which  are  transmitted  by  other  transponders  during  the 
sweep,  may  interfere  with  the  replies  of  the  transponder  of 
interest  in  the  beam.  These  replies  are  termed  FRUIT. 

Based  on  the  reply  rates  of  the  transponders,  the  model 
calculates  the  fruit  rates  that  may  affect  an  identification 
process  between  an  interrogator  and  a  transponder.  Due  to 
the  RSLS -function,  a  reply  is  received  by  the  interrogator 
either  as  a  main  beam  or  as  a  side  lobe  signal.  To  take  care 
of  this  fact,  main  beam  and  side  lobe  replies  are  recorded 
separately. 

In  order  to  shorten  the  discussion  on  fruit  rate  calculation, 
the  following  description  will  concentrate  on  main  beam 
rates.  However,  a  similar  approach  is  implemented  in  the 
model  for  side  lobe  fruit  computation. 

Consider  an  inteiTogator  I  and  a  transponder  T  involved  in  an 
identification  process.  Additionally,  assume  a  potential 
interfering  transponder  T^^^jr  with  a  reply  rate  RR.  Based  on 
the  events 

A  :  Tis  illuminated  by  the  main  beam  of  I  and 
B  :  T^^^jr  is  within  the  main  beam  of  I, 

the  main  beam  fruit  rate,  produced  by  and  received  by  I 
while  inteiTogating  T,  is  given  by  the  equation 

MBFR=P(B/A)RR. 

The  term  P{B !  A)  denotes  the  probability  that  the 
interfering  transponder  is  within  the  main  beam  of  I 
while  sweeping  across  T.  This  probability  is  computed  by  the 
model  as  a  function  of  the  azimuth  angles  from  I  to  T^^^j  and 
T  taking  into  account  the  main  beam  width  of  /. 

The  total  fruit  rate  produced  by  all  interfering  transponders  is 
calculated  by  summing  up  the  individual  contributions. 
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In  addition  to  the  amount  of  fruit,  the  power  levels  of  the 
signals  at  the  interrogator  are  determined.  The  parameters 
transmitter  power  of  the  transponder,  cable  losses  on  the 
transmitting  and  the  receiving  path,  transmitter  and  receiver 
antenna  gains,  and  propagation  losses  are  included  in  the 
power  calculation. 

4.4  Determination  of  interrogator  behaviour 

The  performance  of  an  interrogator  is  characterised  by  the 
parameters  decode  efficiency  {DE),  round  trip  reliability 
(RTR),  and  probability  of  identification  (PID). 

The  decode  efficiency  denotes  the  probability  that  a  reply  is 
received  and  decoded  by  the  interrogator.  Generally,  a  reply 
is  received  and  decoded,  if  it  is  not  overlapped  by  fruit 
replies.  In  case  of  overlapping,  a  reply  may  be  decoded,  if 
the  signal  to  interference  ratio  does  not  exceed  a  decoder 
specific  limit. 

The  calculation  of  the  decode  efficiency  is  performed  in  the 
following  fashion.  Consider  an  interrogator  I  and  a 
transponder  T.  Let  FR  denote  the  total  fruit  rate,  consisting 
of  main  beam  and  side  lobe  fruit,  received  by  I  during 
interrogating  T. 

Just  to  simplify  the  description,  assume  that  the  fruit  replies 
and  a  reply  from  T  have  the  same  signal  length  Trep .  In  that 
case,  the  probability  that  a  reply  of  T  is  overlapped  by  k 
fruit  replies  (0<k<  FR)  can  be  computed  by  applying  the 
binomial  distribution  function 


The  application  of  the  binomial  distribution  is  based  on  the 
assumption  that  the  fruit  replies  are  statistically  independent. 

Again  to  simplify  the  description,  assume  that  all  fruit 
replies  arrive  with  the  same  power  level  PL  given  in  dBm. 
Tlie  total  interfering  energy  within  a  reply  of  T,  produced  by 
k  (0<k<  FR)  overlapping  fruit  replies,  is  derived  from 

PL 

I(k)  =  l0-\og{k\0^^). 

Generally,  the  probability  for  decoding  a  reply  can  be 
deduced  from  a  detection  curve  d(S  /  /) ,  which  is  a  function 
of  the  signal  to  interference  ratio.  The  slope  of  the  curve 
depends  on  the  decoder  design  and  can  be  obtained  by 
measurements. 

Utilising  the  detection  curve,  the  model  computes  the 
probability  for  decoding  a  reply  of  T,  arriving  at  the 
interrogator  with  a  power  level  S  ,  by  the  equation 

FR 

DE=  J^p(k)-diSfI(k)). 

k=0 

Based  on  the  reply  efficiency  of  a  transponder  and  the 
decode  efficiency,  the  success  of  a  full  interrogation-reply 
interaction  is  characterised  by  a  parameter  called  round  trip 
reliability  (RTR).  The  round  trip  reliability  is  given  by 

RTR=  REDE. 

Taking  into  account  the  evaluation  criteria  of  an  interrogator, 
the  probability  of  identification  is  derived  by  the  model  as  a 
function  of  the  round  trip  reliability. 


5  DISCRETE-EVENT  MODEL 

The  simulation  model  introduced  within  this  section  was 
developed  during  1994  primarily  to  enable  the  evaluation  of 
the  mutual  interference  arising  from  interactions  between 
Mode  S  and  IFF  systems.  The  interspersion  of  Mode  S 
transactions  with  IFF  reply-requests,  combined  with  the 
aperiodic  Mode  S  interrogation  schedule,  directed  the  model 
development  effort  to  a  discrete-event  simulation.  Although 
the  model  relates  mainly  to  Mode  S,  it  is  also  capable  to 
analyse  the  performance  of  IFF  systems. 

The  software  of  the  model  is  coded  in  MODSIM  II,  a 
modern  language  for  object  oriented  programming  with 
special  capabilities  for  discrete-event  simulation.  Tlie  model 
is  running  on  a  HP  Workstation  under  UNIX. 

Since  the  simulation  model  is  based  on  an  object-oriented 
approach,  its  structure  will  be  discussed  utilising  the  "Object 
Modeling  Technique"  (OMT)  as  presented  in  [3].  This 
methodology  allows  to  consider  the  model  from  three  related 
but  different  viewpoints,  each  capturing  important  aspects. 
In  accordance  with  these  three  viewpoints, 

•  the  object  structure, 

•  the  functional  structure,  and 

•  the  dynamic  structure 

of  the  discrete-event  model  are  described  within  the 
following  paragraphs. 

5.1  Object  Structure 

Objects  are  data  structures  coupled  with  routines  called 
methods.  Attributes  in  the  object's  data  structure  define  the 
state  of  an  object  at  any  instant  in  time  while  its  methods 
describe  the  actions  which  an  object  can  perform  to  change 
the  states.  The  attributes  and  the  methods  of  an  object  are 
collectively  referenced  as  its  properties. 

An  object  class  describes  a  group  of  objects  with  the  same 
attributes  and  methods,  but  each  object  in  a  class  has  its  own 
identity  and  its  own  values  for  the  attributes. 

To  promote  understanding  of  the  real  world,  the  basic  object 
classes 

•  interrogator, 

•  transponder, 

•  interrogation,  and 

•  reply 

have  been  defined  for  the  discrete-event  model. 

Since  in  reality  an  interrogator  and  a  transponder  represent 
an  assembly  of  different  components,  the  object  classes 
interrogator  and  transponder  are  defined  by  an  aggregation  of 
further  detailed  objects.  An  interrogator  for  instance  consists 
of  a  platform,  antenna,  transmitter-receiver  unit,  signal 
generator,  primary  sensor,  and  decoder  object.  A  transponder 
is  composed  of  a  platform,  antenna,  transmitter-receiver  unit, 
and  processor  object. 

Figure  2  contains  the  object  diagrams  of  the  interrogator  and 
transponder  object  class,  which  reflect  the  aggregation 
relationships. 

5.2  Functional  Structure 

The  functional  structure  of  the  discrete-event  model  is 
determined  by  the  processes  which  are  driven  by  the  objects 
involved  in  the  simulation.  The  basic  processes  are: 
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•  generation  of  interrogations, 

•  propagation  of  inten*ogations, 

•  processing  of  interrogations  and  generation  of  replies, 

•  propagation  of  replies,  and 

•  evaluation  of  replies. 

Figure  3  illustrates  the  functional  structure  of  the  discrete- 
event  simulation  program.  The  processes  are  drawn  as 
ellipses.  The  objects  driving  a  process  are  attached  to  the 
graph. 

5.3  Dynamic  Structure 

The  discrete-event  simulation  program  models  a  sequence  of 
processes  which  are  challenged  by  the  activities  of  the 
objects.  Since  many  objects  are  involved  in  the  simulation  at 
any  instant  of  simulation  time,  multiple  concuiTent  processes 
can  occur.  To  keep  track  of  all  these  processes,  the 
programming  language  MODSIM  II,  which  is  utilised  for  the 
discrete-event  model,  keeps  a  pending  list.  This  pending  list 
is  an  ordered  list  of  all  objects  which  have  scheduled 
activities.  The  object  with  the  most  imminent  activity  is 
ordered  first  in  the  list.  Once  the  activity  of  an  object 
scheduled  for  a  particular  instant  of  simulation  time  has  been 
carried  out,  the  simulation  clock  is  advanced  to  the  next 
point  in  simulation  time,  when  the  next  activity  of  an  object 
has  been  scheduled. 

The  dynamic  structure  of  the  model  is  deteimined  by  the 
time  dependent  activities  of  the  objects  which  are  driving  the 
processes  specified  in  the  functional  structure.  In  the 
following  paragraphs  these  processes  are  described  in  more 
detail  with  special  emphasis  on  the  dynamic  behaviour  of  the 
involved  objects. 

5,3.7  Generation  of  Interrogations 

The  process  of  generating  interrogations  is  driven  by  the 
signal  generator  object  in  conjunction  with  the  primary 
sensor  object  of  an  inteiTOgator. 

To  model  the  dynamic  behaviour  of  a  primary  radar,  a  state 
variable  is  assigned  to  the  primary  sensor  object.  For  a 
continues  interrogator,  the  state  variable  is  set  to  "active" 
during  the  total  simulation  time.  In  case  of  an  automatic 
interrogator,  the  initial  state  of  the  variable  is  "passive".  The 
variable  becomes  "active"  each  time  a  target  enters  the  main 
beam.  It  is  reset  to  "passive",  when  no  longer  any  target  is 
illuminated  by  the  antenna  main  beam.  In  case  of  an 
autospecific  and  a  manual  operated  interrogator,  it  is 
randomly  decided  whether  the  state  is  set  to  "active"  when  a 
target  enters  the  main  beam.  For  the  purpose  of  determining 
the  targets  of  an  interrogator,  an  ideal  primary  sensor  is 
assumed  able  to  detect  each  target  within  the  coverage. 

The  first  time  a  signal  generator  is  triggered  to  generate  an 
interrogation  is  determined  randomly.  As  soon  as  the 
simulation  clock  is  advanced  to  this  point  in  simulation  time, 
the  state  variable  of  the  associated  primary  radar  is  checked. 
If  the  state  is  set  to  "active",  the  interrogation  is  generated, 
otherwise  the  interrogation  is  suppressed.  In  the  case  of 
generation,  a  new  instance  of  an  interrogation  object  is 
created.  Then  the  signal  generator  waits  for  the  next  time  to 
be  triggered.  This  loop  is  repeated  until  the  simulation  end  is 
reached. 


Tlie  state  diagram  within  Figure  4  illustrates  the  dynamic 
model  of  the  signal  generator  concerning  the  generation  of 
interrogations.  The  different  states  are  drawn  as  rounded 
boxes.  The  conditions  that  have  to  be  fulfilled  for  a  transition 
from  one  state  to  another  are  attached  within  square  brackets. 

5.3.2  Propagation  of  interrogations 

When  an  interrogation  has  been  generated  by  an  interrogator, 
a  new  instance  of  a  interrogation  object  is  created  by  the 
simulation  model.  The  purpose  of  the  interrogation  object  is 
to  model  the  propagation  of  an  interrogation  and  its  arrival  at 
transponders. 

The  propagation  times  are  determined,  which  are  required  by 
the  interrogation  to  travel  from  the  generating  interrogator  to 
the  transponders  deployed  in  the  environment.  The 
transponders  are  stored  in  an  ordered  list  with  respect  to  the 
propagation  times.  The  arrival  of  the  interrogation  at  the 
closest  transponder  is  scheduled  first.  When  the  simulation 
clock  is  advanced  to  this  point  in  time,  a  message  is  sent  to 
the  associated  processor  of  the  transponder.  If  there  are 
further  transponders,  the  arrival  at  the  next  transponder  is 
scheduled.  This  cycle  is  repeated  until  the  interrogation  has 
arrived  at  all  transponders  in  the  environment. 

In  case  of  arrival,  the  signal  strength  of  the  interrogation  at 
the  transponder  is  computed  including  the  parameters 
transmitter  power,  cable  losses  on  the  transmitting  and  the 
receiving  path,  transmitter  and  receiver  antenna  gains,  and 
propagation  loss.  The  power  levels  are  calculated  for  the 
basic  interrogation  as  well  as  for  the  corresponding  ISLS- 
pulse. 

5.3.3  Processing  of  interrogations 

The  processing  of  inteiTOgations  is  performed  by  the 
processor  object  assigned  to  each  transponder. 

Initially,  the  processor  object  of  a  transponder  is  in  the  state 
"not  occupied"  and  thus,  ready  to  receive  and  process 
interrogations.  As  soon  as  an  interrogation  arrives  at  a 
transponder  with  a  power  level  above  the  receiver  sensitivity, 
a  check  is  performed  to  determine  whether  the  interrogation 
is  received  without  any  interference.  This  check  includes  the 
possibilities  that  the  transponder  is  occupied  by  a  previous 
interrogation  or  that  the  transponder  is  receiving  another 
interrogation,  thereby,  causing  overlapping  of  the  signals.  In 
case  of  an  occupied  transponder,  the  arriving  interrogation 
fails  and  does  not  change  the  current  state  of  the  processor. 
If  two  signals  overlap  during  the  receipt,  it  depends  on  the 
power  levels  of  the  signals  whether  one  of  the  interrogations 
may  succeed.  If  neither  of  the  intenogations  can  be 
successfully  received,  it  is  because  they  are  said  to  be 
garbled.  The  resistance  to  garble  depends  on  the  transponder 
design  and  can  be  analytically  expressed  in  terms  of  a 
detection  curve.  The  detection  curve  of  a  transponder  can  be 
integrated  into  the  processor  model. 

When  an  inteiTOgation  is  successfully  received,  it  is  checked 
whether  a  main  beam  or  a  side  lobe  signal  has  been 
recognised.  Main  beam  and  side  lobe  interrogations  are 
distinguished  by  comparing  the  power  levels  of  the 
interrogation  and  the  con*esponding  ISLS-pulse. 

In  the  case  of  a  side  lobe  receipt,  a  suppression  time  is 
induced.  During  the  time  of  suppression,  the  processor  is  in 


12-7 


the  "occupied"  state  and  does  not  accept  any  interrogation. 
At  the  end  of  suppression,  the  state  of  the  processor  is  reset 
to  "not  occupied"  and  new  interrogations  are  accepted. 

Having  received  a  main  beam  signal,  the  transponder 
becomes  "occupied"  too  and  can  not  be  accessed  by  an 
interrogation  until  the  state  is  changed  to  "not  occupied". 
During  the  occupancy  time,  the  received  interrogation  is 
processed.  When  the  simulation  time  has  advanced  to  the 
end  of  the  processing  stage,  the  corresponding  reply  is 
transmitted.  As  a  consequence,  a  new  reply  object  is  created. 
As  soon  as  the  time  required  for  transmission  is  elapsed,  an 
additional  recovery  time  is  provided  and  at  its  end  the  state 
of  the  processor  is  set  to  "not  occupied",  thereby,  being 
ready  to  accept  a  new  interrogation. 

The  dynamic  model  of  the  processor  object  is  shown  by  the 
state  diagram  in  Figure  5. 

5.3.4  Propagation  of  replies 

Each  time  a  transponder  transmits  a  reply,  a  new  instance  of 
a  reply  object  is  created  by  the  simulation  model.  The 
purpose  of  the  reply  object  is  to  model  the  propagation  and 
the  arrival  of  replies  at  interrogators. 

The  propagation  times  are  determined,  which  are  required  by 
the  reply  to  travel  from  the  generating  transponder  to  the 
interrogators  involved  in  the  simulation.  The  interrogators 
are  stored  in  an  ordered  list  with  respect  to  the  propagation 
times.  The  arrival  of  the  reply  at  the  closest  interrogator  is 
scheduled  first.  As  soon  as  the  simulation  clock  is  advanced 
to  this  point  in  time,  a  message  is  sent  to  the  associated 
decoder  of  the  interrogator.  If  there  are  further  interrogators 
in  the  ordered  list,  the  arrival  at  the  next  interrogator  is 
scheduled.  This  cycle  is  repeated  until  the  reply  has  arrived 
at  all  interrogators. 

For  each  arrival,  the  signal  strength  of  the  reply  at  the 
interrogator's  receiver  is  calculated  based  upon  the 
transmitter  power,  the  cable  losses  on  the  transmitting  and 
the  receiving  path,  the  transmitter  and  receiver  antenna 
gains,  and  the  propagation  loss.  In  the  case  of  an  interrogator 
equipped  with  a  receiver  side  lobe  suppression  (RSLS),  the 
power  levels  of  the  reply,  received  via  the  sum  and  the 
difference  antenna,  are  determined. 

5.3.5  Evaluation  of  replies 

The  decoding  and  evaluation  of  replies  is  modelled  by  the 
decoder  object  assigned  to  an  interrogator. 

When  a  decoder  gets  a  message  indicating  the  arrival  of  a 
reply,  the  receiving  procedure  is  started.  An  interference 
check  is  made  against  other  replies.  If  the  reply  is 
overlapped,  the  power  levels  of  the  overlapping  signals  are 
compared.  Based  on  the  detection  curve  of  the  decoder, 
which  provides  the  probability  of  detection  as  a  function  of 
the  signal  to  interference  ratio,  it  is  determined  whether  the 
reply  is  detectable.  A  reply  unable  to  be  decoded  is  ignored. 

If  the  decoder  is  capable  to  detect  the  reply  and  if  the 
interrogator  is  equipped  with  a  receiver  side  lobe  suppression 
(RSLS),  a  comparison  of  the  power  levels  received  via  sum 
and  difference  antenna  pattern  is  performed.  If  the  reply 
turns  out  to  be  received  via  the  side  lobes,  the  signal  is  not 
further  processed. 


A  main  beam  reply,  successfully  received  and  decoded,  is 
correlated  with  the  generating  transponder  and  a  reply 
counter  is  updated.  As  soon  as  the  sweep  of  the  interrogator's 
antenna  main  beam  across  this  target  is  completed,  the 
number  of  received  replies  is  evaluated.  Taking  into  account 
the  evaluation  algorithm  of  the  interrogator,  the  code 
detection  or  the  identification  is  declared. 

The  dynamic  behaviour  of  a  decoder  object  is  illustrated 
within  the  state  diagram  in  Figure  6. 

6.  MODEL  OUTPUTS 

Both  models  introduced  in  the  previous  sections  provide 
graphical  outputs  of  the  simulation  environment  and  results. 

Tlie  simulation  environment  is  displayed  reflecting  positions 
and  types  of  the  platfonns  deployed.  A  map  can  be  inserted 
containing  geographical  information  like  borders,  coastlines, 
rivers,  or  cities. 

At  the  end  of  a  simulation  run,  the  operational  area  and  -  if 
relevant  -  the  operational  sectors  of  an  inteiTOgator  can  be 
displayed.  Optionally,  all  targets  within  the  operational 
coverage  or  only  a  subset  of  targets  can  be  inserted. 

A  subset  may  be  determined  by  any  criteria.  Typical  criteria 
are  for  instance  predefined  limits  for  probability  of 
identification,  reply  efficiency,  or  any  other  parameters.  In 
case  of  a  given  criteria,  only  the  tai’gets  are  displayed  which 
do  not  fulfil  the  criteria.  Labels  can  be  attached  to  each 
target  indicating  the  identity  or  any  other  information  of  the 
aircraft. 

Concerning  simulation  results,  statistics  gathering  is 
accomplished  by  the  models  for  a  variety  of  parameters.  The 
most  important  parameters,  which  can  be  used  as  measures 
of  IFF  system  performance,  are: 

•  main  beam  and  side  lobe  interrogation  rates, 

•  reply  efficiency  and  reply  rates, 

•  main  beam  and  side  lobe  fruit  rates, 

•  decode  efficiency,  and 

•  probability  of  identification. 

The  models  perform  statistical  evaluations  of  these 
parameters  providing  maximum,  minimum,  mean  value, 
standard  deviation,  and  distribution  function.  The  statistical 
data  are  displayed  in  graphical  form. 

As  a  special  feature,  the  discrete-event  model  is  capable  of 
graphical  animation,  which  promotes  the  understanding  of 
the  dynamic  behaviour  of  the  various  objets  involved  in  the 
simulation.  The  generation  of  interrogations,  their  arrival  at 
the  transponders,  the  generation  of  replies,  and  the  arrival  at 
the  interrogators  are  displayed. 

7.  CONCLUSIONS  AND  REMARKS 

Tliis  paper  has  focused  on  the  introduction  of  two  simulation 
models  for  IFF  system  performance  analysis. 

The  first  model  is  based  on  a  probabilistic  approach.  It 
depends  on  the  application  of  statistical  laws.  Some 
assumptions  are  made  like  the  statistical  independence  of 
interrogations  and  replies,  which  are  valid  for  dense  signal 
environments.  Due  to  this  fact  and  because  the  program  is 
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very  cheap  in  computing  time,  the  model  is  primarily 
suitable  to  handle  large  scenarios. 

The  second  model  is  designed  as  a  discrete-event  simulation 
program.  This  methodology  is  capable  of  very  accurate 
results,  given  good  quality  equipment  data  and  propagation 
calculation  algorithms.  However,  it  is  more  expensive  in 
computing  time. 

Finally,  it  should  be  mentioned  that  both  models  are  not  only 
applicable  to  explore  the  effects  of  self-interference  caused 
by  interrogations  and  fruit.  The  models  can  also  be  utilised 
for  the  analysis  of  ECM  impact  on  the  IFF  system 
performance.  Furthermore,  problems  concerning  frequency 
compatibility  aspects  of  IFF  with  civil  SSR  systems  can  be 
investigated. 
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Figure  1:  Establishment  of  a  simulation  environment 


Figure  2:  Object  structure 


Figure  3;  Functional  structure 


signal  generator 


Figure  4:  Dynamic  structure  of  signal  generator 


Figure  5:  Dynamic  structure  of  processor 


Figure  6:  Dynamic  structure  of  decoder 


15-1 


Applications  of  Multisensor  Data  Fusion  to  Target  Recognition 


Michel  MORUZZIS,  Nathalie  COLIN,  Gilbert  MILHEM 
Thomson-CSF,  Division  SDC 

7  rue  des  Mathurins,  BP  10,  92223  Bagneux  Cedex,  France 


Abstract 

Target  Recognition,  which  is  a  key 
function  for  ensuring  the  successful 
execution  of  conflicts  and  wars,  will 
be  based  on  multisensor  data  fusion. 
For  instance,  the  recent  developments 
concerning  the  future  Surface-Air 
surveillance  and  tracking  systems 
design  are  based  on  the  use  of  both 
multifunction  sensors  and  integration 
of  data  coming  from  sensors  such  as 
Radars,  Infra  Red  Search  and  Track, 
Electronic  Support  Measures  and 
Electro-Optical  devices. 

The  performance  and  reliability  of 
target  recognition  is  improved  by 
making  the  best  use  of  both 
complementarity  and  redundancy 
between  sensors. 

Redundancy  allows  validation  of 
target  class  membership  assessment 
while  complementarity  gives  access  to 
a  variety  of  parameters  which  refines 
the  recognition  level,  improves  the 
target  discrimination  performance 
and/or  reduces  the  time  needed  to 
achieve  a  given  recognition 
performance . 

An  efficient  multisensor  recognition 
system  must  make  the  best  use  of 
several  kinds  of  informations; 
basically  one  can  distinguish: 

.  instantaneous  physical  properties 
of  the  target  such  as  target  Radar 
Cross  Section,  Doppler  spectrum  or 
High  Resolution  Range  Profile  for  a 
radar,  angular  extent  and/or  image 
texture  for  an  IRST,  waveform 
parameters  (such  as  carrier 
frequency,  pulse  repetition 
interval  and  pulse  lenght)  for  an 
ESM, 

.  target  behaviour  properties  such  as 
the  velocity,  acceleration,  rate  of 
climb  or  style  of  manoeuvre  (such 
as  "terrain  following”  or  "pop¬ 
up")  . 

The  first  kind  of  knowledge  relies 
mainly  on  sensor  waveform  generation, 
signal  processing  and  extraction 
expertise,  while  the  second  is  more  a 
matter  of  mastery  of  data  processing 
and  multisensor  tracking. 

Fusing  these  informations  means  that 
one  must  process  the  data  both 


spatially  (e.g.  from  different 
sensors  or  from  different  parameters 
extracted  from  the  same  sensor)  and 
temporally  (e.g.  from  scan  to  scan  or 
frame  to  frame)  which  implies  that 
the  recognition  function  must  be 
perceived  as  a  dynamic  process. 

Together  with  processing  these  data 
in  order  to  optimise  the  recognition 
performance,  the  recognition  system 
can  participate  to  improve  : 

. sensors  performances  by  optimising 
the  sensor  signal  processing  and 
ecxtraction  according  to  the 
supposed  target  type  (as  for 
instance  optimising  the  Constant 
False  Alarm  Ratio  processing 
according  to  the  target  size) , 

. data  processing  (multisensor 
tracking)  by  giving  new 
capabilities  for  track  initiation, 
plot-to-track  and/or  track-to-track 
correlation, 

.  overall  system  efficiency  by 
managing  the  sensors  ressources  (as 
for  instance  by  requesting  the 
necessary  waveform  at  the  useful 
time)  in  order  to  optimise  the 
trade-off  between  the  recognition 
performance  and  the  system  overall 
load/Low  probability  of  Intercept 
property. 

The  proceeding  remarks  together  with 
more  practical  considerations  such  as 
data  flows  and  data  structures  show 
that,  even  if  the  data  to  process  and 
the  processing  methods  are  different, 
target  tracking  and  target 
recognition  must  be  performed  in 
tight  cooperation. 

The  objective  of  this  paper  is  to 
highlight  some  aspects  of  multisensor 
data  fusion  applied  to  target 
recognition  in  the  aim  of  defining  an 
operational  system. 

After  having  introduced  the  subject, 
the  paper  gives  a  description  of  a 
multisensor  system  and  processing 
architecture  which  can  be  used  for 
simultaneous  target  recognition  and 
tracking. 

Basic  fusion  techniques  such  as 
Bayesian  Inference,  Evidence  Theory 
and  Fuzzy  Logic  are  then  introduced, 
some  practical  results  being 
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presented  for  illustrating  these 
techniques . 

Finally  a  data  processing 
architecture  including  both  tracking 
and  recognition  functions  is 
presented  and  respective  merits  of 
conventional  techniques  are  discussed 
with  regard  to  the  different 
processing  functions. 

1.  INTRODUCTION 

Complex  situation  assessment  systems 
require  more  and  more  precise 
informations  for  maintaining  the 
necessary  level  of  security.  This  is 
the  case  for  Military  Control  and 
Command  systems  such  as  Air  Defence 
Centers,  Combat  Management  Systems 
for  maritime  forces  or  Battlefield 
Command  Systems,  but  also  for  civil 
applications  such  as  Air  Traffic 
Management  or  Airport  Surface 
Control . 

All  of  these  systems  rely  on  the  same 
generic  elements  : 

.  sensors  to  detect,  locate  and 
identify  the  objects, 

.  communications  to  transfer  data 
from  sensors  to  centers  and 
commands  from  centers  to  sensors, 

.  control  centers  where  data  are 
merged  and  analysed  and  where 
decisions  are  made  regarding  the 
situation  as  it  is  perceived, 

.  defence  systems  and/or  control 
procedures  as  decided  by  the 
authority . 

Recent  events  have  highlighted  a  very 
strong  demand  in  terms  of 
identification,  mainly  to  avoid 
fratricid  actions .  Identification 
normally  relies  on  specific  sensors 
(IFF)  or  procedures  (flight  plans) , 
but  complex  situations  may  require 
more  complete  identification  means 
involving  non  cooperative  sensors  as 
well . 

Such  considerations  led  to  view  data 
fusion  as  a  function  in  which 
positional  and  identification  data 
are  to  be  processed  together. 

2.  MULTI SENSOR  SYSTEM  DESCRIPTION 

2 . 1  Technical  functions 

The  main  technical  sub-functions  of  a 
multisensor  data  fusion  system  are 
summarized  below: 

Data  acquisition  :  this  function  is 
necessary  to  acquire  the  sensor 
output  and  manage  an  associated 
memory;  it  acts  as  an  interface 


between  sensors  and  the  data  fusion 
system. 

Data  alignment:  it  is  necessary  to 
transform  the  data  (plots  and/or 
tracks)  output  from  various  sensors 
into  a  common  coordinate  and  time 
frame.  Data  alignment  is  the  key 
function  on  which  lies  the  data 
fusion  principles  (synchroneous , 
asynchroneous  or  hybrid  update) ;  it 
must  be  used  for  transforming  the 
quality  informations  (e.g.  standard 
deviations)  as  well. 

Track  initiation:  the  objective  of 
the  data  fusion  is  to  supply  a  unique 
track  for  each  object  being  detected 
by  any  sensor  of  the  system,  it  is 
then  necessary  to  initiate  this  track 
from  either  plots  or  tracks  supplied 
by  the  sensors.  In  general  some  time 
integration  is  used  when  false  alarm 
reduction  is  required.  In  order  to 
optimise  track  initiation  in  a 
multisensor  system  one  must  therefore 
take  in  account  the  false  alarm 
characteristics  of  each  sensor . 

In  order  to  improve  the  track 
initiation  in  a  dense  environment  and 
also  when  data  from  different  sensors 
are  used  simultaneously,  track 
initiation  must  rely  on  both 
positional  and  identification  (if 
available)  data. 

Correlation :  this  function  is  used  to 
determine  wether  a  new  sensor  data 
corresponds  to  an  existing 
(multisensor)  track,  it  is  mainly 
based  on  gating  logic  for  coarse 
correlation  and  more  refined 
algorithms  using  data  accuracies  for 
fine  correlation.  It  must  be 
performed  after  data  alignment  (which 
can  consist  to  update  the  track  to 
the  new  data  time  or  conversely) . 

Association:  in  a  dense  object 
environment  and/or  for  high  false 
alarm  rate  sensors,  several 
correlations  can  be  possible  (several 
plots  for  the  same  track  or  several 
tracks  for  the  same  plot  or  both 
cases) .  In  this  situation  one  must 
use  a  decision  algorithm  based  on 
some  association  likelihood 
assessment;  the  choice  of  this 
algorithm  can  have  a  strong  impact  on 
the  data  fusion  structure  (see  "track 
maintenance"),  the  simplest  methods 
are  based  on  a  "Nearest  Neighbour" 
approach  while  more  sophisticated 
"Multi  Hypothesis  Tracking'' 
techniques  becomes  now  available. 
Again,  if  identification  data  are' 
available,  they  must  be  used  for 
reducing  the  risk  of  possible  wrong 
association. 
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Track  update :  it  is  performed  to 
generate  the  new  track  state  using 
the  new  data  associated  to  the  track. 
It  is  in  general  performed  in  a 
recursive  way,  using  some  kind  of 
Kalman  filter  which  is  well  suited  to 
manage  variations  in  both  accuracies 
and  sampling  time. 

However,  targets  may  have  sudden 
changes  in  heading  and  speed  which 
can  require  some  state  adaptation  in 
the  Kalman  filter;  current  methods 
range  from  the  simplest  {Variable 
State  Noise  filter)  to  more 
sophisticated  ones  (Interacting 
Multiple  Model,  for  instance) . 
Identification  data  can  be  updated  in 
the  same  way  as  more  conventional 
positional  data.  However  the  updating 
techniques  are  different  and  depend 
strongly  on  the  nature  of  the 
available  data  (see  below) . 

Track  maintenance:  it  is  dedicated  to 
track  file  management,  allocation  of 
track  numbers,  track  deletion  and 
memory  management, 

2.2  Architectures 

Depending  on  several  factors  such  as 
the  type  and  number  of  sensors, 
communication  constraints  or  system 
complexity,  multisensor  architectures 
may  vary  from  decentralized  systems 
where  each  sensor  processes  as  much 
data  as  possible  in  order  to  send  the 
fusion  center  as  little  data  as 
possible  up  to  centralized  structures 
where  raw  sensor  data  are  massively 
processed  by  the  fusion  center. 

In  terms  of  identification  data,  a 
decentralized  architecture  requires 
that  each  sensor  proceeds  to  some 
level  of  analysis  concerning  the 
target  nature,  which  means  that  the 
fusion  center  deals  with  merging 
symbolic  data.  A  centralized  system 
is  a  system  where  raw  data  are 
transfered  to  the  fusion  center  which 
can  merge  such  numeric  data  from 
different  sensors  before  taking  a 
decision  about  the  target  nature. 

Even  for  a  centralized  architecture, 
it  can  be  more  efficient  to  process 
data  at  the  sensor  level;  this  is  the 
case  when  contextual  knowledge  must 
be  handled  in  order  to  analyse  the 
results .  An  example  is  given  by  the 
High  Resolution  Range  Profile 
produced  by  a  coherent  radar  ;  for 
extracting  useful  informations  from 
such  profile  one  must  know 
informations  such  as  clutter 
environment,  waveform  parameters, 
Doppler  and  Range  filter 
parameters, . . .  All  of  these 
informations  are  to  be  transferred 
with  the  profile  if  the  fusion  center 
wants  to  analyse  its  content.  As  long 


as  that  increases  the  data  flow 
without  improving  the  expected  result 
it  seems  worthwhile  to  process  the 
Range  profile  at  the  radar  level  in 
order  to  extract  the  relevant 
characteristics  for  target 
recognition. 

Time  integration  is  also  a  factor  on 
which  target  recognition  must  be 
based,  especially  when  such  a  precise 
identification  is  required  that  it 
implies  a  dynamic  process  with  sensor 
management  for  instance. 

A  generic  multisensor  architecture  is 
presented  in  Figure  1.  This  figure 
shows  three  main  components  which 
participates  to  target  recognition: 

.  a  local  features  fusion,  located 
at  the  sensor  level;  this  function 
supplies  local  declarations  to  the 
fusion  center, 

.  a  centralized  features  fusion, 
located  at  the  fusion  center 
level  ;  this  function  processes 
local  features  (after  alignment) 
and  supplies  «  instantaneous  » 
declarations . 

.  a  centralized  declaration  fusion, 
which  is  the  core  of  the 
identification  function  and  which 
(recursively)  merges  all  sources 
of  recognition  in  order  to  supply 
the  best  result  at  the  current 
time . 


3.  IDENTIFICATION  DATA  FUSION 
TECHNIQUES 

Among  the  numerous  existing 
techniques  for  merging  identification 
data,  recent  analysis  refer  to  three 
main  methods  : 

3.1  Bayesian  technicmes 

It  is  the  most  common  method,  based 
on  conventional  probability 
description.  It  requires  some  a 
priori  knowledge  onto  the  problem  to 
solve  (conditional  probability 
density  functions,  a  priori 
probabilities  and  decision  costs) ,  it 
can  be  used  for  both  continuous  and 
discrete  data  and  can  relatively 
easily  be  structured  for  a  recursive 
implementation . 

If  some  decision  is  required,  it  can 
be  viewed  as  a  two  steps  methods: 
class  probability  evaluation  then 
decision  making  procedure. 

Bayes  method  assumes  that  an  object 
can  belong  to  one  (and  only  one) 
class  among  N. 

If  a  measurement  (x)  is  made  by  the 
sensor,  the  “a  posteriori" 
probability  P{I/x)  that  the  object 
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belongs  to  class  I  is  given  by  the 
relationship  : 

P(x  / 1).  P(I) 

P(/  /  X)  =  - 

IPCX/ J).P(J) 

J 

Two  different  informations  are  then 
necessary : 

"a  priori"  conditional  probability 
density  functions  P(x/J) 

"a  priori"  probabilities  P{J) 

If  a  decision  is  to  be  taken,  Bayes 
introduced  the  notion  of  "decision 
cost"  Cjj which  represents  the  cost  one 
has  if  one  decides  that  the  class  is 
I  if  it  was  J  in  reality. 

The  resulting  class  will  be  K  if  it 
minimizes : 

Ck 

B_ayesian  technique  can  be  used  for 
merging  different  measures  {x  may  be 
a  vector) ,  it  can  also  be  used  to 
merge  discrete  data  (x  may  be  a 
vector  of  decision,  the  a  priori 
conditional  probability  density 
functions  are  then  equivalent  to 
confusion  matrices) . 

It  will  be  shown  below  that  it  can 
also  be  used  for  a  recursive 
identification  integration. 

3.2  Evidence  Theory 

Developped  by  Shafer  and  Demptser,  it 
relies  on  some  uncertainty 
description  and  is  based  on  a  more 
general  class  description  (called  the 
"frame  of  discernment")  than  the 
Bayesian  ones;  here  one  also 
considers  every  disjunction  of 
classes  in  addition  to  the  elementary 
ones . 

A  "mass"  is  assigned  to  each 
elementary  proposition  in  order  to 
represent  the  confidence  one  has  for 
this  proposition  ("support"  and 
"plausibility"  are  also  used  to 
represent  the  degree  of  belief) . 

Rules  of  combination  are  provided  for 
merging  data  from  several  sources  of 
knowledge  (for  instance  several 
sensors  or  several  sources  of  the 
same  sensor) . 

The  core  of  Evidence  Theory  is  the 
"rule  of  combination"  of  informations 
supplied  by  two  sensors.  It  is 
assumed  that  each  sensor  supplies  a 
set  of  "masses"  m(Pj),  where  Pj  is  an 
element  of  the  frame  of  discernment. 
The  result  of  the  combination  is 
given  by  : 

m(Pj^  )  =  {Fj ).  ^2  (Pj  )  /  (1  -  ^) 


In  the  above  relationship, (I, J)  is 
such  that  P^  is  the  intersection  of  P, 
and  P.,  and  X  is  given  by  : 

where  (I,J)  is  such  that  the 
intersection  of  Pj  and  P^  is  the  empty 
set . 


3 . 3  Fuzzy  logic  method 

This  method  is  also  used  when  some 
uncertainty  is  to  be  taken  into 
account  regarding  the  problem  to 
solve.  It  relies  mainly  on  two  basic 
functions:  a  "Membership  Function" 
used  to  described  how  a  given  class 
can  be  represented  on  the  basis  of  a 
given  attribute,  and  a  "Possibility 
Distribution"  which  describes  how  the 
actual  value  of  a  given  attribute  can 
be  distributed  when  some  measurement 
of  this  attribute  is  available. 

From  these  elementary  functions  one 
can  derive  a  "Possibility"  and  a 
"Necessity"  which  describe  the 
confidence  and  uncertainty  related  to 
this  attribute.  Merging  different 
attributes  is  done  with  simple 
computations  such  as  "min"  and  "max" 
functions,  using  relative  weights  on 
each  attribute. 

The  merging  procedure  can  be  done  in 
a  recursive  way;  this  technique  can 
be  used  for  merging  different  kind  of 
data  (continuous,  discrete,  logical, 
already  " fuzzied" , . . . )  and  is  well 
suited  when  no  learning  phase  is 
possible  (for  instance  kinematic  data 
based  recognition)  and  for  sensor 
error  measurement  handling  (using  the 
possibility  distribution) . 

The  basic  fuzzy  logic  relationship 
are  summarized  below: 

For  a  given  parameter  (X.)  ,  one  knows 
the  functions  M(x.)  and  D(xJ  which 
represent  respectively  the  Membership 
Function  and  the  Possibility 
Distribution.  From  these  functions 
one  can  compute  the  Possibility  (P.) 
and  Necessity  (N.)  according  to: 

Py  =  )j| 

Nj  =  Min^Max^M{Xj  ),1  -  D(xy  )]J 


The  fusion  of  several  results  is 
obtained  by  using  different  logical 
inference (conjunction  or  disjunction) 
and  different  weightings  (WJ  . 
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The  weighted  conjunction  leads  to; 


P  =  Min] 
i 

Max\\ 

N  =  Min^ 
i 

The  weighted  disjunction  gives: 

P  =  Max{Min[n'j,Pi^ 

N  = 

4.  APPLICATION  TO  IDENTIFICATION  DATA 
FUSION 

Introducing  identification  in  a 
inultisensor  fusion  system  leads  to 
design  a  new  fusion  architecture  in 
which  identification  data  : 

»  is  time  updated, 

.  is  used  for  improving  the  plot  to 
track  association, 

,  can  be  completed  by  extracting 
knowledge  from  kinematic  data. 

Figure  2  shows  a  typical  diagram  of 
fusion  algorithm  taking  in  account 
the  above  functions .  This  diagram 
assumes  some  local  (sensor)  Bayesian 
classification,  each  plot  containing 
some  positional  and  class  data  (Xp, 

Cp) ,  the  tracking  output  being 
represented  by  (Xt,  Ct) , 

Possible  implementation  of  sub¬ 
functions  are  detailed  hereafter. 

4.1  Recursive  identification  update 

At  a  given  time  k,  assuming  that  the 
tracked  target  can  belong  to  a  class 
I  among  N  possible  classes,  one  needs 
to  evaluate: 

P(I  /  Cpk) ,  where  Cpk  represents  the 
set  of  elementary  decisions  (Cp{l) , 
Cp(2) , . . . ,  Cp(k) ) 

It  can  be  shown  that  P(I  /  Cpk)  can 
be  written  in  a  recursive  form  (if 
elementary  decisions  are 
independant) : 

P{IIC  )  =  I/>(//C^^_l).P(C.(A:)//)/D 
pk  I  ^  ^ 

where  P{Cp{k)  /  I)  is  an  element  of 
the  confusion  matrix  corresponding  to 
the  decision  Cp(k)  (current 
decision) ,  and  D  is  the  normalization 
factor  : 

£)  =  SP(J/C^^_l)P(C^W/y) 

This  procedure  is  illustrated  on 
Figure  4  which  represents  the 
probability  of  classification  as  a 
function  of  time,  for  a  situation 


involving  four  different  targets. 
Confusion  matrices  (see  Figure  3)  are 
issued  from  radar  experimental 
results  obtained  by  a  short  term 
Doppler  analysis  of  four  different 
helicopters  (two  cases  are  showed 
depending  on  the  type  of  signal 
analysed  -blade  flash  or  hub-) . 

It  was  assumed  that  for  each 
helicopter  the  observation  sequence 
was  the  same  (four  times  a  hub  signal 
and  one  time  a  blade  flash  signal) . 

It  is  also  assumed  that  the 
classifier  could  give  its  confusion 
matrix  for  each  decision;  each 
helicopter  type  had  the  same  a  priori 
probability  (0.25). 

It  can  be  seen  that  for  each  case  the 
recursive  integration  allowed  the 
decision  to  converge  to  the  right  one 
and  that  accurate  decisions  (such  as 
these  obtained  on  a  blade  flash) 
could  greatly  improve  the  result  (see 
for  instance  target  type  2  at  scan 
6) .  This  shows  that  fusion  quality 
strongly  relies  on  a  good  knowledge 
of  input  data  quality  (such  as  the 
confusion  matrix  in  the  above  case) . 

4 .2  Plot-to-track  Identification  data 
association 

In  a  dense  environment,  plot  to  track 
association  can  be  improved  when 
identification  data  are  available  for 
both  plots  and  tracks . 

Basically  the  plot  to  track 
association  is  based  on  some 
likelihood  assessment  using 
positional  data  (for  instance  the 
Kalman  innovation) . 

Using  both  positional  and 
identification  data  needs  to  use  the 
same  kind  of  normalised  "distance", 
the  most  logical  choice  being  the 
probability  (which  can  be  easily 
computed  for  positional  data) . 

Again  assuming  that  both  plots  and 
tracks  contain  a  class  information 
(Cp  and  Ct  as  suggested  above) ,  one 
can  compute  the  "class  distance"  as 
being  the  probability  Pc  that  the 
plot  and  the  track  belong  to  the  same 
class .  Assuming  that  each  class  has 
the  same  a  priori  probability,  one 
finds  the  following  result: 

=  Z  P(/  /  )\p{Cp  (k)  //)/£>] 

where  D  is  the  normalisation  factor  : 

D  =  lP{c^(k)/J) 

This  relationship  can  be  generalised 
to  the  multiplot  and  mutitrack  case 
by  simply  evaluating  every  plot  to 
track  probability. 
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It  can  be  seen  that  evaluating  these 
probabilities  leads  very  simple 
computations  compared  to  the 
equivalent  positional  data 
probabilities .  Introducing 
identification  for  improving  plot  to 
track  association  corresponds  to  only 
a  very  limited  increase  in  algorithm 
complexity. 


4.3  Kinematic  data  identification 


Target  spatial  behaviour  {such  as 
altitude,  speed,  acceleration,  rate 
of  climb,  . . )  obviously  contains 
information  relative  to  the  target 
type.  Extracting  this  information  is 
somehow  difficult  mainly  for  two 
reasons : 

.  target  behaviour  can  not  be 
«learned»  in  the  conventional 
sense.  This  means  that  one  must 
use  some  specific  knowledge 
representation  instead  of 
measurement  based  statistics, 

.  kinematic  data  are  supplied  by  a 
tracking  algorithm  and  can  be 
strongly  corrupted  by  measurement 
noise. 

Fuzzy  reasoning  gives  answers  to 
these  two  points  and  is  then 
certainly  a  good  candidate  for 
kinematic  data  identification. 

The  Membership  Function  (see  M(Xi)  in 
3.3  above)  is  used  to  define  the 
possible  values  which  can  be  taken 
for  a  given  class,  while  the 
Possibility  Distribution  is  used  to 
describe  the  possible  actual  values 
when  one  has  a  measured  value  and  its 
accuracy . 


Figure  5  illustrates  the  basic  fuzzy 
logic  mechanisms  with  one  class  (C) , 
one  parameter  (x)  and  one  measurement 
(xo,  ao) . 


5.  CONCLUSIONS 

Introducing  target  identification  in 
future  multisensor  systems  is  one  of 
the  keys  to  achieve  the  level  of 
security  required  by  complex 
situation  assessment  such  as 
conflicts  and  wars,  but  also  for 
civil  applications  such  as  Air 
Traffic  management. 

An  analysis  of  how  this  introduction 
can  be  made  shows  that: 

.  identification  fusion  architecture 
can  be  designed  in  the  same  way 
than  positional  fusion 
architecture, 

identification  fusion  must  be  seen 
as  a  process  involving  both 
"spatial”  and  "temporal"  merging, 

,  it  is  essential  to  supply  the 
quality  of  the  data  to  be  merged 
(for  instance  a  standard 
deviation,  a  probability  vector,  a 
confusion  matrix,  a  Dempster- 
Shafer  mass,..)  together  with  the 
data  itself, 

among  existing  techniques,  Bayes 
methods  and  Fuzzy  logic  are  prime 
candidates.  Evidence  Theory  is 
promising  but  still  requires  some 
analysis  effort  concerning  the 
"mass"  assigment  in  a  real 
sensor  environment, 

there  is  no  "best  choice"  of  a 
technique  among  others,  but  the 
need  to  apply  the  "good"  technique 
to  solve  each  specific  problem. 
Challenge  is  then  rather  to 
develop  fusion  systems  where 
different  techniques  are  used 
together  and  exchange  data, 

R&D  efforts  are  to  be  put  on  both 
exchanges  between  techniques , 
input  data  characterisation 
methods,  and  reference  data  base 
collecting  are  modeling. 
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features 

Figure  1  :  Hybrid  multisensor  system  architecture 


Figure  2  :  Fusion  algorithm  diagram 
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ABSTRACT 

Aircraft  identification  is  essential  in  any  air-defence  scenario. 
Without  a  robust  classification  capability  no  effective  threat 
evaluation  can  be  performed.  A  prominent  aircraft  recognition 
technique  is  based  on  the  exploitation  of  a  one-dimensional 
image  of  a  target,  a  range  profile.  In  this  paper,  we  employ 
four  different  classification  techniques,  all  based  on  shift 
invariant  distances,  and  a  method  to  compare  them.  Two  of  the 
techniques  are  based  on  Radial  Basis  Functions  for  which  a 
novel  technique  to  optimize  the  number  of  free  parameters  is 
presented.  The  application  is  on  real  radar  data,  where  a  true 
separation  between  train-  and  test  profiles  is  accomplished. 

The  classification  results  are  encouraging.  As  an  example,  a 
qualitative  statement  is  given  about  the  best  of  the  four 
classifiers  to  be  used  in  combinations  of  two  scenarios  and 
four  applications. 

1.  INTRODUCTION 

An  important  aircraft  identification  technique,  Identification 
Friend  Foe,  relies  on  the  cooperation  of  the  target.  If,  in  war- 
or  crisis  time,  the  aircraft  fails  to  cooperate  for  whatever 
reason  the  only  save  conclusion  for  the  interrogator  is  that  the 
aircraft  is  hostile. 

This  incomplete  decision  process  caused  serious  cases  of 
fratricide.  In  April  1994,  two  Blackhawk  (friendly)  helicopters 
were  shot  down  in  the  no-fly  zone  of  Iraq.  This  incident 
underlined  again  the  importance  of  an  additional  identification 
capability  such  as  NCTR  (Non-Cooperative  Target  Recogni¬ 
tion). 

Currently  we  are  investigating  the  NCTR  potential  of  High 
Range  Resolution  (HRR)  range  profiles.  Measurement  of  these 
signatures  is  relatively  easy  and  the  requirements  for  motion 
compensation  are  moderate  or  the  compensation  may  even  be 
omitted.  Additionally,  range  profile  classification  is  applicable 
at  almost  all  aircraft  orientations. 

In  the  literature,  several  approaches  to  classify  range  profiles 
are  reported.  Selection  of  a  feature  vector  from  the  spectral 
components  of  a  range  profile  is  reported  by  Garber  etal[\], 
DeWitt  [2]  and  Kouba  [3].  Classification  of  this  vector  is 
carried  out  by  a  nearest  neighbour  rule,  a  Hidden  Markov 


Model  and  a  recurrent  neural  network,  respectively.  The  latter 
two  have  the  interesting  ability  to  process  sequences  of  range 
profiles.  Baras  and  Wolk  [4]  showed  the  feasibility  of  range 
profile  classification  on  multiple  resolution  levels  using 
wavelets. 

In  real  measurements,  the  absolute  positions  of  the  scatter 
returns  in  a  range  profile  are  undefined.  It  requires  that  the 
classification  method  should  be  shift-invariant.  A  promising 
solution  to  this  problem  is  the  use  of  correlation  filters  [5].  In 
this  paper  we  investigate  the  potential  of  a  shift  invariant 
profile-to-profile  distance.  Once  it  is  defined,  all  classification 
techniques  that  are  based  on  these  pair  distances  are  available. 
Earlier  results  on  such  a  distance  metric  using  a  nearest 
neighbour  classifier  (section  3.4)  are  reported  by  Novak  [6]. 
Four  different  classification  methods  are  devised  and  tested. 
Two  of  them  are  based  on  the  Nearest  Neighbour  rule,  the 
other  two  are  implementations  of  a  Radial  Basis  Functions 
network.  In  this  study  a  thorough  test  on  real  radar  data  from 
inflight  aircraft  is  carried  out.  An  important  property  of  the 
used  data  set  is  that  the  train-  and  test  profiles  were  measured 
independently. 

Furthermore,  we  present  a  method  to  compare  the  classifiers. 
Clearly,  an  important  comparison  criterion  is  the  error  on  an 
independent  test  set.  With  an  eye  on  future  applications  for  a 
range  profile  classifier  we  believe  that  it  is  important  to 
include  the  classification  speed  in  the  comparison  as  well. 

Two  less  important  parameters  are  the  time  needed  for  training 
a  classifier  and  the  size  of  the  classifier. 

Finally,  we  select  for  all  combinations  of  two  scenarios  and 
four  applications  the  most  appropriate  classifier.  Although 
these  choices  are  rather  tentative  given  the  moderate  amount 
of  data  that  is  considered,  it  clearly  demonstrates  the  employed 
method. 

The  organisation  of  this  paper  is  as  follows:  The  next  section 
reviews  the  physics  of  range  profiles,  section  3  describes  the 
used  distance  metric  and  the  four  classification  techniques. 
Then,  section  4  establishes  the  approach  to  compare  classifi¬ 
cation  techniques.  Section  5  shows  the  results  on  real  radar 
data  and,  finally,  section  6  gives  the  conclusions. 


Paper  presented  at  the  AGARD  MSP  3rd  Symposium  on  ''Tactical  Aerospace  C^I  in  Coming  Years’", 
held  in  Lisbon,  Portugal  from  15th  May  to  18th  May  1995,  and  published  in  CP-557. 
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2.  RANGE  PROFILES 

Figure  1  shows  the  contour  of  an  aircraft  and  its  range  profile. 
The  profile  can  be  viewed  as  a  projection  of  the  aircraft 
scatterers  onto  the  line  of  sight.  It  thus  shows  the  radar  cross 
section  as  a  function  of  range. 


Fig.  1 :  The  aircraft  is  illuminated  from  the  left  side.  Each  strip 
represents  a  range  cell.  The  contributions  of  the  scat¬ 
terers  in  each  strip  are  summed  to  constitute  a  single 
range  profile  element. 

For  the  generation  of  range  profiles,  we  need  a  radar  that  is 
able  to  emit  a  high  bandwidth- waveform.  This  can  be  done 
either  with  a  single  short  pulse,  or  with  a  burst  of  pulses  at 
linearly  increasing  carrier  frequencies  [7]. 

Due  to  coherent  summation  of  aircraft  scatterers  (speckle),  the 
exact  shape  of  the  range  profiles  depends  strongly  on  aspect 
angle.  However,  the  overall  profile  shape  does  not  change 
significantly  (see  for  example  figure  3)  as  long  as  the  aircraft 
scatterers  do  not  move  outside  one  range  resolution  cell. 

For  the  available  data,  the  maximum  change  in  aspect  angle  to 
avoid  this  rotational  range  migration  is  approximately 
1.5  degrees.  It  is  very  difficult  to  determine  the  aircraft  aspect 
angle  with  this  accuracy.  Consequently,  a  simple  look-up  table 
approach  -  a  measured  profile  and  its  aspect  angle  is  compared 
to  the  profiles  in  a  data  base  with  the  same  aspect  angle  -  is  not 
applicable  [5]. 

Another  approach  is  therefore  to  consider  aspect  angle  bins 
that  are  several  times  larger  than  the  error  in  aspect  angle.  The 
procedure  is  to  construct  a  classifier  for  each  bin.  Then,  for  an 
unknown  profile,  retrieve  its  aspect  angle,  select  the  appropri¬ 
ate  bin  and  assign  a  class  with  the  corresponding  classifier. 
Evidently,  an  extra  mismatch  probability  will  occur,  because  a 
profile  from  class  1  may  look  like  a  profile  from  class  2,  as 
seen  at  a  different  aspect  within  the  bin. 

For  the  data  set  we  consider  in  this  paper  the  errors  on  the 
aspect  angles  are  witnin  five  degrees.  All  profiles  have  aspect 
angles  with  absolute  values  ranging  from  0  to  20  degrees  and 
are  placed  in  a  single  bin. 


3.  RANGE  PROFILE  CLASSIFICATION 

3.1  Definitions 

Two  sets  of  independently  measured  range  profiles  within  a 
single  bin  are  available,  the  input  set  and  the  test  set.  A  subset 
of  the  input  set,  the  train  set,  is  used  for  training  a  classifier. 
The  profiles  in  the  input  set,  train  set  and  test  set  are  randomly 
ordered  and  are  named  r/,  t  =  1 , . . . ,  Mnput,  p/,  /  =  1 , . . . , 
A^train,  and  q/,  /  =  1, . . . ,  Mest  respectively. 

A  classifier  is  fully  determined  by 

1.  the  classification  technique  and 

2.  the  train  set. 

The  classes  of  all  profiles  are  known.  This  enables  us  to  train 
and  test  a  classifier.  Clearly,  in  an  operational  situation  there  is 
no  test  set  available. 

3.2  Sliding  Euclidean  Distance 

All  our  classification  methods  are  based  on  profile-to-profile 
distances.  The  absolute  positions  of  the  reflections  in  the 
profile  depend  strongly  on  the  distance  to  the  target.  As  we 
cannot  estimate  this  distance  accurately  enough  to  place  the 
reflections  on  an  objective  position,  we  must  use  a  shift 
invariant  distance. 

Suppose  we  have  two  range  profiles  xi  and  X2,  length  a  , 
elements  jc(1  ),...,  x(  a ).  Then  we  define  the  distance  D  as 
the  minimum  Euclidean  distance  over  all  shifts: 


D(XpX2)=  min  j'^[xi(i  + j)- X2(i)f 

. 

The  shifts  are  cyclical,  that  is  jci(  a  -i-  j)  =  xi(j). 

3.3  Compression  and  normalisation  of  profiles 

In  profile  classification  using  the  Sliding  Euclidean  distance  it 
is  advantageous  to  lift  the  weak  scatterers  in  the  range  profile 
relative  to  the  strong  scatterers  so  that  they  can  play  a  role  in 
the  profile  matching  as  well.  Several  choices  can  be  made  for 
such  a  compression,  e.g.  a  log-scale  or  a  power  function  with  a 
power  less  than  one. 

Current  investigations  concern  the  search  for  the  optimum 
compression  function.  Preliminary  results  show  that  a  power 
function  with  a  power  works  satisfactorily. 

After  the  compression,  the  profiles  need  to  be  normalized,  as 
the  magnitudes  of  the  reflections  depend  strongly  on  the 
absolute  sensitivity  of  the  radar  and  the  distance  at  which  the 
aircraft  was  measured.  As  neither  the  sensitivity  nor  the  exact 
distance  of  the  aircraft  is  known,  we  normalise  the  compressed 
profiles  such  that  the  sum  of  squares  of  the  profile  elements 
equals  one. 

3.4  Nearest  Neighbour 

The  nearest  neighbour  rule  decides  that  the  class  of  a  profile 
from  the  test  set  is  the  class  of  the  nearest  profile  in  the  train 
set.  Here  ‘nearest’  is  with  respect  to  the  chosen  distance 
metric  D. 

A  simple  extension  to  this  technique  is  to  search  for  the 
k(k>2)  nearest  neighbours,  giving  k  class  declarations.  The 
class  that  occurred  most  frequently  is  assigned  to  the  profile 
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from  the  test  set.  Experiments  showed  that  this  extension  did 
not  give  significant  differences  in  the  classification  results. 
Therefore  we  will  only  consider  a  1 -nearest  neighbour  in  this 
paper. 

3.5  Condensed  Nearest  Neighbour 

A  drawback  of  the  nearest  neighbour  technique  is  the  large 
computational  effort  necessary  for  the  classification.  For  each 
profile  for  which  classification  is  desired,  we  have  to  compute 
all  distances  to  the  profiles  in  the  train  set  again.  This  is  even 
more  a  problem  in  our  application,  because  the  chosen 
distance  measure  D  is  computationally  expensive. 

The  technique  we  will  apply  here  to  reduce  the  computational 
burden  is  based  on  the  idea  that  a  profile  that  is  far  from  the 
decision  boundary  has,  on  average,  far  less  influence  on  the 
outcome  of  the  nearest  neighbour  classifier  than  a  profile  that 
is  near  the  decision  boundary.  Therefore  we  might  as  well  skip 
this  profile  and  save  the  computation  time. 

It  is  possible  that  a  profile  does  not  contribute  to  the  decision 
boundary  at  all,  as  it  is  completely  surrounded  by  other 
profiles  from  the  same  class.  Skipping  it  does  not  alter  the 
outcome  of  a  nearest  neighbour  rule.  However,  in  our  applica¬ 
tion  this  situation  seldom  occurs  as  a  profile  is  of  very  high 
dimension  and  thus  almost  always  defines  a  part  of  the 
decision  boundary.  This  means  that  in  virtually  all  cases  the 
classification  accuracy  is  reduced  if  a  profile  is  removed. 

In  this  paper,  we  use  the  condensing  algorithm  [8].  To  arrive 
at  the  condensed  subset  of  the  train  set,  two  complementary 
subsets  of  this  set,  named  A  and  B,  are  defined.  Place  the  first 
profile  from  the  train  set,  pi,  in  A,  the  remaining  profiles,  p2, 

. . . ,  pA^train*  The  method  proceeds  as  follows: 

1 .  Use  the  nearest  neighbour  rule  to  classify  the  first  profile 
in  B  with  the  profile(s)  in  A.  If  it  is  classified  correctly 
with  the  nearest  neighbour  rule,  leave  it  in  B,  otherwise, 
place  it  in  A.  Repeat  this  operation  for  all  profiles  that  are 
left  in  B. 

2.  If  in  step  1  not  a  single  profile  has  been  transferred  from  B 
to  A,  or  if  B  is  empty  then  terminate.  Else  return  to  step  1. 

After  termination,  A  contains  the  condensed  subset.  For 
classification,  the  nearest  neighbour  rule  is  applied  using  the 
condensed  subset  instead  of  the  full  train  set. 

3.6  Radial  Basis  Functions 

Radial  Basis  Functions  (RBF)  provide  a  way  to  construct  a 
function  that  maps  vectors  from  a  high  dimensional  space  onto 
a  lower  dimensional  space  [9].  As  the  only  inputs  for  this 
method  are  distances  between  profiles  we  can  use  the  sliding 
Euclidean  distance  D  to  make  the  method  suitable  for  range 
profile  classification.  The  advantage  of  the  used  RBF  imple¬ 
mentations  compared  to  a  nearest  neighbour  technique  is  the 
large  reduction  of  classifier  size  and  classification  effort. 

From  the  train  set,  L  profiles  are  selected  to  serve  as  centres  c/, 
/  =  1, .  . . ,  L.  (The  next  two  subsections  3.7  and  3.8  describe 
the  used  selection  methods.)  The  pair  distances  between  the 
centres  and  a  train  profile  p/  enter  the  RBF  network  and  form 
the  elements  of  a  distance  vector  d/  with  elements: 


Then,  a  non-linear  transform  using  a  Gaussian  function 
^2 

^(r)  =  e  2  (2) 

is  applied  to  each  of  the  elements  in  the  distance  vector,  giving 

bu=mil  (3) 

Multiplication  of  the  vector  b,-  =  {bu, . . . ,  bn^by  a  weight 
matrix  W  and  addition  of  a  bias  vector  wo  gives,  for  each  train 
profile,  the  output  o/. 

o,-  =  Wq  +  Wbi  (4) 

In  the  training  phase,  the  weights  wo  and  W  are  chosen  such 
that  the  outputs  are  as  close  as  possible  to  unit  vectors  in  a 
y-dimensional  space,  where  y  is  the  number  of  classes. 

Train  profiles  from  class  1  are  mapped  as  close  as  possible 
onto  the  output  e7  =  (l,0,...,  0)^,  train  profiles  from  class  2 
onto  62  =  (0,  1, ... ,  0)^,  et  cetera. 

Hence  the  training  of  the  Radial  Basis  Functions  network  boils 
down  to  finding  the  least  squares  solution  for  wo  and  W  using 
equation  4  for  all  train  profiles.  This  is  an  attractive  property 
of  the  Radial  Basis  Functions  approach:  although  it  is  able  to 
construct  any  complex  non-linear  decision  boundary,  the 
weights  can  be  found  by  linear  methods  [9]. 

For  classification  we  simply  compute  the  output  for  a  test 
profile  qt  using  the  distances  D  to  the  centres  and  equations  3 
and  4.  If  the  closest  unit  vector  to  the  output  is  ej  then  class  j  is 
assigned  to  the  test  profile. 

In  the  next  sections  we  will  address  the  problems  of  choosing 
the  centres  and  selecting  the  number  of  centres. 

3.7  Radial  Basis  Functions  with  Random  Centre 
Selection 

A  good  first  choice  for  the  centres  is  to  select  them  randomly 
from  the  train  profiles.  One  must  be  careful,  however,  about 
the  number  of  centres  to  choose.  Each  extra  centre  adds  an 
extra  degree  of  freedom  to  fit  the  train  profiles.  If  we  take  too 
few  centres,  the  approximation  will  be  too  coarse.  If  we  take 
too  many  centres  (but  less  than  the  number  of  train  profiles), 
also  the  noise  on  the  profiles  will  be  fitted  (‘overfitting’).  In 
both  cases,  the  generalisation  capabilities  of  the  classifier  will 
be  worse  than  with  an  intermediate  number  of  centres. 

To  find  the  optimum  number  of  centres  we  devised  the 
following  algorithm: 

1 .  Select,  randomly,  half  of  the  profiles  from  the  train  set, 
and  use  them  as  evaluation  set.  Use  the  other  half  as  de¬ 
sign  set. 

2.  Choose,  randomly,  a  profile  from  the  design  set  (one  that 
has  not  been  chosen  earlier)  and  copy  it  to  the  centre  set. 

3.  Find  the  weights  using  the  centre  set  and  the  design  set 
from  equation  4. 

4.  Compute  the  outputs  o/  for  each  of  the  evaluation  profiles. 
Compute  the  sum  of  the  errors  II  0/-e;  II  where  tj  are  the 
desired  outputs  corresponding  to  the  class  of  the  evalua¬ 
tion  profiles.  This  is  called  the  evaluation  error. 

5.  Repeat  steps  2,  3  and  4  until  all  design  profiles  (apart  from 
one)  are  used  as  centre. 


dii  =  DiPi.c,) 


(1) 
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Similarly  to  step  4  it  is  instructive  to  compute  the  design  error 
as  well. 

Although  this  error  decreases  monotonically  as  the  number  of 
centres  increases,  the  evaluation  error  will  reach  a  minimum 
for  a  certain  number  of  centres.  See  figure  2.  The  best  choice 
for  the  number  of  centres  is  therefore  at  the  minimum  value  of 
the  evaluation  error. 

poor  poor 

generalization  generalization 

caused  by  too  .  due  to 

few  degrees  of  generalization 

freedom 


size 

- -  Number  of  centres 

Fig.  2:  As  the  number  of  centres  increases  the  network  is  able 
to  represent  the  design  profiles  better,  i.e.  the  design 
error  tends  to  zero.  However,  the  true  classification  ca¬ 
pability  is  revealed  by  the  error  on  an  independent 
evaluation  set. 

3.8  Radial  Basis  Functions  with  Gram-Schmidt  Centre 
Selection 

A  procedure  to  select  the  best  centres  from  the  design  set  is  to 
use  a  Gram-Schmidt  orthonormalization  technique.  Here  we 
will  confine  ourselves  to  a  qualitative  description,  for  details 
we  refer  to  [10]. 

As  in  the  Random  Centre  Selection,  the  first  step  is  to  employ 
the  first  part  of  the  train  set  for  designing  the  classifier  and  the 
other  part  for  evaluation.  Then  we  search  for  that  profile  in  the 
design  set  that  gives  the  best  least-squares  solution  if  used  as  a 
centre.  At  each  next  step,  we  add  another  profile  to  the  centre 
set  that  gives  the  best  improvement  of  the  least-squares 
solution. 

Instead  of  the  computation  of  the  least-squares  solutions,  Chen 
etal  [10]  devised  an  efficient  Gram-Schmidt  orthonormaliza¬ 
tion  procedure  to  select  the  best  centres. 

As  in  the  random  centre  selection,  we  compute  the  classifica¬ 
tion  error  on  the  independent  evaluation  set  and  choose  that 
number  of  centres  where  the  evaluation  error  has  a  minimum. 

4.  COMPARISON  OF  CLASSIFIERS 

Often,  classification  techniques  are  compared  in  terms  of  their 
errors  on  a  test  set  only.  For  most  practical  applications  three 
more  properties  define  the  usefulness  of  a  classifier.  The 
following  list  gives  the  four  measurable  classifier  properties 
that  are  of  interest. 


a\  Classification  error  [%  false  on  independent  test  set] 
a2  Computational  effort  needed  for  one  classification 
[#  floating  point  operations] 

as  Computational  effort  needed  for  training  the  classifier 
[#  floating  point  operations] 

a4  Memory  required  to  store  the  trained  classifier  [#  of 
bytes]. 

Ideally,  each  of  these  quantities  equals  zero.  In  practice,  for 
each  classification  technique  there  will  be  a  trade-off  between 
these  four  properties  which  can  be  found  by  varying  the  size  of 
the  train  set. 

For  example,  let  us  consider  a  classifier  that  uses  the  nearest 
neighbour  technique  {as  =  0)  and  a  small  sized  train  set.  Then 
the  classification  error,  a\,  will  decrease  if  the  train  set 
increases.  This  also  implies,  however,  that  more  distances 
have  to  be  computed  and  it  thus  results  in  a  larger  a2  and  a4. 

To  choose  the  right  classifier  we  would  like  to  have  weight 
functions,  ro,-  (monotonously  increasing)  so  that  the  quantity 

Y,0)i(ai)  (5) 

i=} 

is  minimized  with  respect  to  ai, . . . ,  04-  Unfortunately,  we  do 
not  have  these  functions  available,  but  we  can  make  a  few 
simplifying  but  realistic  assumptions  to  tackle  the  problem. 

The  first  one  is  that  the  most  important  parameters  in  a 
military  context  are  a\  and  a2.  The  time  needed  for  training 
{as)  is  of  much  lesser  importance,  because  it  can  be  done  off¬ 
line.  The  size  of  the  trained  classifier  is  generally  also  less 
significant.  Besides  that  04  is  (almost)  linearly  related  to  aifor 
the  classification  techniques  we  consider.  Therefore  we  do  not 
have  to  minimize  <24  by  itself.  For  the  remainder  of  this  paper, 
we  will  therefore  focus  on  ai  and  02  only. 

We  do  not  make  a  choice  for  coi  and  0)2  either,  but  construct  a 
large  number  of  classifiers  to  demonstrate  the  trade-off 
between  a\  and  a2.  For  example,  if  the  user  wishes  a  certain  a\ 
he  may  find  in  a  single  curve  the  classifier  that  has  the  smallest 
a2. 

At  this  point,  we  also  want  to  stress  that  not  only  the  applica¬ 
tion  (e.g.  surveillance  or  aircraft  radar)  is  decisive  for  the 
classifier  choice,  but  also  the  scenario  (crisis  or  wartime).  As 
an  illustration  table  1  shows  roughly  the  importance  of  correct 
classification  and  fast  classification  as  a  function  of  the 
application  and  the  scenario. 

This  table  shows  in  qualitative  terms  that  in  times  of  crisis  it  is 
more  important  to  have  a  reliable  answer  then  to  have  a  quick 
answer.  In  wartime  it  is  of  greatest  important  to  have  a  fast 
answer. 

5.  RESULTS 

5.1  Available  data 

We  have  an  input  set  available  of  357  profiles  of  four  different 
aircraft  from  an  S-Band  radar.  The  number  of  elements  of  the 
profiles  is  128.  These  profiles  were  gained  in  six  different 
aircraft  flights. 
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scenario 

crisis 

wartime 

classifier  property 

correct  class,  fast  class. 

correct  class.  fast  class. 

application 

SHORAD 

HIMAD 

Fighter  aircraft 

Surveillance 

+  0 

+  - 

+  0 

+  - 

0  + 

0  0 

0  + 

0 

Table  1 ;  Relative  importance  of  classification  properties  for  application  and  scenario  in  terms  of  minus  signs  (less 
importance),  zeroes  (moderate  importance)  and  plus  signs  (high  importance).  Here  SHORAD  means 
SHOrt  Range  Air  Defense  and  HIMAD  High  to  Medium  Air  Defense  (e.g.  HAWK,  PATRIOT). 


In  five  other  measurements,  339  profiles  were  obtained  from 
the  same  four  aircraft.  These  profiles  made  up  an  independent 
test  set. 

For  each  profile,  an  approximate  aspect  angle  is  available.  The 
absolute  aspect  angles  (we  assume  symmetry  around  aspect 
angle  0)  are  in  the  range  of  0  to  20  degrees  from  head-on.  The 
errors  on  the  angles  are  believed  to  be  within  5  degrees,  the 
elevation  is  approximately  zero. 

As  stated  in  subsection  3.3  the  profiles  were  compressed  with 
a  power  of  1/4  and  normalised.  Figure  3  shows  some  examples 
of  compressed  and  normalised  profiles  from  the  four  different 
classes  and  from  the  input-  and  test  set.  Each  of  the  three 
profiles  in  one  class  and  one  set  was  measured  during  the  same 
flight.  This  means  that,  although  the  aspect  angle  is  inaccurate, 
the  change  in  aspect  angle  (as  indicated  above  each  profile)  is 
more  accurately  defined. 

5.2  Classification  experiment 

In  this  section  we  investigate  the  properties  of  the  classifica¬ 
tion  techniques  of  chapter  3.  To  this  end,  we  construct  a  large 
number  of  classifiers  using  the  four  techniques  and  varying 
train  sets  to  monitor  the  trade-offs  between  the  classification 
speed  and  the  classification  error. 

Carry  out  the  following  steps  for  A^train  =  8,  24,40, ...  ,152: 

1 .  Choose,  randomly,  Wtrain/4  profiles  per  class  from  the 
input  set  and  use  them  as  train  set. 

2.  Construct  the  classifiers 
NN  (Nearest  Neighbour) 

CNN  (Condensed  Nearest  Neighbour) 

RR  (Radial  Basis  Functions  with  Random  Centre  Se¬ 
lection) 

RGS  (Radial  Basis  Functions  with  Gram-Schmidt  or¬ 
thonormalization) 
for  this  train  set. 

3.  Classify  all  profiles  in  the  test  set  using  these  classifiers. 
Compute  the  percentage  of  false  classifications.  This  gives 
a\ .  Also  keep  track  of  the  number  of  flops  used  for  classi¬ 
fying  a  single  profile  {ut). 

4.  Repeat  steps  1-3  thirty  times  and  average  a\  and  02. 

The  results  are  shown  in  figures  4  and  5. 

Figure  4  shows  that  a  fairly  good  classification  rate  can  be 
achieved  with  only  a  small  number  of  profiles  per  class  in  the 
train  set.  For  example  the  nearest  neighbour  technique  needs 
only  40  train  profiles  (on  average  one  profile  per  class  per  two 
degrees)  to  achieve  a  classification  error  less  than  1 1  %.  It 
suggests  that  a  rather  crude  coverage  of  aspect  angle  suffices 


for  reasonable  classification,  although  one  must  be  aware  that 
the  performance  is  favoured  by  the  small  number  of  classes. 
For  all  sizes  of  the  train  set,  the  nearest  neighbour  technique 
has  the  best  classification  rate.  This  technique  apparently 
makes  the  best  use  of  the  available  data.  For  small  sizes  of  the 
train  set,  both  Radial  Basis  Function  techniques  have  poor 
classification  rates.  This  is  because  half  of  the  profiles  has  to 
be  used  for  evaluation.  If  the  train  set  increases,  this  effect 
becomes  less  important. 


CLASS  1 


CLASS  2 


CLASS  3 


CLASS  4 


INPUT  INPUT  INPUT  TEST  TEST  TEST 


TITD — ~ 

+0.2 

T04 

shAv 

TOT) - 

A 

T0:5 - 

T0:4 - 

jiw 

+0.( 

+0.2 

+0.4 

+0.0 

+0.2 

+0.4 

jc 

+0:2 

A- 

+0.4 

+075 

A 

+0:2 

To:4 

sjAnk*ifi 

+0.0 

+0.2 

+0.4 

A. 

+0.0 

+0.2 

J'kv 

+0.4 

JL 

Fig.  3:  Examples  of  compressed  and  normalised  profiles  of 
four  different  aircraft,  near  head-on.  The  input  set  is 
shown  on  the  left  hand  side  and  the  independent  test 
set  on  the  right  hand  side.  In  the  upperleft  corner,  the 
aspect  angle  difference  (in  degrees)  relative  to  the  left¬ 
most  of  the  three  profiles  is  shown.  As  can  be  seen,  the 
small  scale  variations  (speckle)  are  unpredictable 
whereas  the  overall  appearance,  in  most  cases,  Is 
similar. 

The  condensed  nearest  neighbour  has  an  approximately  6% 
higher  classification  error  rate  than  the  normal  nearest  neigh¬ 
bour  for  all  sizes  of  the  train  set.  As  stated  in  section  3.5,  the 
condensing  procedure  deletes  profiles  that  somehow  contrib¬ 
ute  to  the  decision  boundaries. 

The  Radial  Basis  Functions  using  a  Gram-Schmidt  centre 
selection  has  a  somewhat  better  classification  rate  than  the 
RBF  using  a  random  centre  selection.  For  larger  input  sets,  the 
difference  tends  to  vanish. 

The  classification  effort  (figure  5)  is  closely  related  to  the 
number  of  profiles  that  is  present  in  the  classifier. 

In  the  nearest  neighbour  case,  all  profiles  are  used  in  the 
classifier  -  the  CNN  classifiers  use  the  condensed  profiles 
only.  The  classification  effort  is  exactly  linearly  related  to  the 


17-6 


Fig.  4:  Average  percentage  wrong  (a\)  as  a  function  of  train 
set  size. 

number  of  profiles  in  the  train  set  (NN)  or  the  number  of 
condensed  profiles  (CNN). 

The  left-over  profiles  in  an  RBF  classifier  are  the  centres.  The 
major  part  of  the  computations  arises  from  the  profile-to- 
profile  distance  evaluations  -  a  small  number  of  extra  compu¬ 
tations  is  necessary  for  the  non-linear  transform  (equation  2) 
and  the  matrix  multiplication  (equation  4). 

The  two  plots  show  that  in  the  CNN-,  RR-  and  the  RGS 
classifiers  only  a  very  small  number  of  profiles  is  left  over, 
compared  to  the  nearest  neighbour.  It  means  that  redundant  or 
nearly  redundant  profiles  are  removed  at  the  cost  of  an 
increased  classification  error. 

As  the  important  parameters  are  a\  and  a2,  figure  6  shows  the 
trade-offs  between  classification  rate  and  classification  speed 
for  the  four  classification  techniques. 

From  this  figure  one  can  decide  which  classifier  is  most 
appropriate  for  a  particular  classification  purpose.  The  simple 
approach  is  to  choose  a  desired  classification  error  on  the 
vertical  axis,  move  horizontally  until  the  first  curve  in  the  plot 
is  reached.  This  classifier  should  be  used  as  it  is  the  most  rapid 
one.  For  example,  if  one  desires  a  classification  between 
approximately  9%  and  14%  an  RGS  classifier  is  the  best 
choice.  The  required  size  of  the  train  set  can  be  found  in 
figures  4  or  5. 

Conversely,  figure  6  can  be  utilised  to  find  the  best  classifier 
given  a  desired  classification  speed.  E.g.  if  one  is  willing  to 
carry  out  10,000  flops  for  one  classification,  a  CNN  classifier 
is  the  best  choice,  because  it  has  the  minimum  error  of  ap¬ 
proximately  17%. 

If  one  desires  the  minimum  classification  error  possible,  a 
nearest  neighbour  is  appropriate,  but  it  will  take  a  long  time  to 
answer. 

Returning  to  the  table  1  we  may  insert,  using  figure  6,  the 
most  appropriate  classification  techniques;  see  table  2.  We 
want  to  stress  that  filling  in  this  table  is  merely  a  demonstra¬ 
tion  of  the  method  of  classifier  selection  -  for  a  decisive 
answer  on  which  techniques  to  use,  larger  scaled  experiments 
have  to  be  carried  out. 


Fig.  5:  Average  classification  effort  for  resulting  classifier  (<22) 
as  a  function  of  train  set  size. 

6  CONCLUSIONS 

In  this  paper  we  described  a  successful  classification  test  on 
range  profiles.  The  profiles  used  for  training  and  those  for 
testing  were  acquired  in  strictly  separated  aircraft  flights  and 
covered  a  wide  aspect  angle  range  of  20°.  Still,  the  best 
classification  results  were  within  10%  error.  Although  these 
results  are  favoured  by  the  small  number  of  classes,  they  are 
very  encouraging  for  the  applicability  of  this  technique  for 
NCTR. 

All  classification  techniques  we  considered  were  based  on 
profile-to-profile  distances.  The  best  rates  were  found  using  a 
simple  nearest-neighbour  rule.  In  this  paper  we  demonstrated, 
however,  that  for  most  cases  this  is  not  the  best  technique  if 
one  includes  the  classification  speed  into  the  comparison  as 
well.  It  shows  that  the  Condensed  Nearest  Neighbour  and  the 
Radial  Basis  Functions  with  Gram- Schmidt  orthonormaliza¬ 
tion  have  a  more  favourable  trade-off  between  classification 
rate  and  -speed. 


Fig.  6:  Average  classification  effort  {a2)  vs  Average  classifica¬ 
tion  rate  (ai)  (zoomed). 
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scenario 

crisis 

wartime 

application 

SHORAD 

HIMAD 

Fighter  aircraft 
Surveillance 

RGS  medium  train  set 

RGS  large  train  set 

RGS  medium  train  set 

RGS  large  train  set 

CNN  small  train  set 

CNN  small  train  set 

CNN  small  train  set 

CNN  medium  train  set 

Table  2:  Best  classification  technique  given  scenario  and  application. 
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After  having  summarized  the  Mission  Planning 
evolution  during  the  last  two  decades  this  paper 
introduces  the  Mission  Planning  family  or  ^sterns 
concept  and  presents  an  example  :  the  CIRCE  2001 
family  in  service  with  the  French  Air  Force.  In 
conclusion  the  to  day’s  trends  are  briefly  analyzed. 

1.  Mission  Planning  history 

Schematically  one  can  identify  three  steps  in 
technology. 

-  First  generation  systems  (before  1985) 

Due  to  limited  performance  these  equipment  brought 
only  a  partial  automation  of  the  tasks  to  be  achieved 
manually  by  the  crew,  the  main  improvement  was 
related  to  performance  computation  and  data  transfer 
cartridge  loading.  One  can  say  that  coming  out  of 
cartridge  has  made  such  systems  necessary. 

We  notice  than,  despite  a  digitizing  table,  the  paper 
maps  handling  remains  a  time  consuming  task  for  the 
pilot. 

-  Second  generation  systems  (1985  -  1990) 

These  systems  are  fully  digitized  thanks  to  emerging 
technologies  such  as  map  digitization,  graphic 
processors,  optical  disks,  and,  very  soon,  tne  use  of 
graphic  workstations  providing  simultaneously 
computing  power  ana  graphic  power. 

The  first  system  without  any  paper  maps  is  the 
PALOMA  ^stem  created  in  1986  by  5  AG  EM  to  plan 
the  Mirage  2000N  missions  -including  the  ASMP 
planning-  then  extended  to  the  Super  Etendard  fitted 
with  the  same  missile  in  the  naval  aviation.  More  than 
300  maps  were  assemblied  in  an  optical  disk  along  with 
the  relevant  terrain  elevation  model.  This  system  is 
made  of  a  computer  and  a  graphic  processor  since 
graphic  workstation  were  not  available. 

The  systems  based  on  work  stations  appear 
approximately  two  years  later,  the  AFA  in  Germany 
dedicated  to  the  Tornado,  the  MSS  II  in  the  US  having 
the  F16  and  Fill  capability. 

In  these  systems  the  mission  planning  process  is 
completely  digital.  Nevertheless  they  are  mainly 
dedicated  to  a  given  aircraft  and  lack  growth  capability. 

-  Third  generation  systems  (from  1990) 

The  tremendously  increasing  performances  of 
computers,  graphic  engines,  storage  media  added  to 
software  open  architecture  made  it  possible  to  give 
systems  multi  ship  capability.  Such  evolution  has  been 
seen  simultaneously  in  France  and  in  the  States  where 
the  MSS  III  program  initially  aimed  to  the  Tactical  Air 
Command  au*craft  has  been  enlarged  to  become  finally 
the  AFMSS  (Air  Force  Mission  Support  System)  taking 
into  account  all  of  the  USAF  aircraft. 

In  addition  to  this  extension,  horizontal  in  some  wav, 
another  extension,  a  vertical  one  became  also  possible 
thanks  to  the  flexibility  of  hardware  and  software.  This 


is  the  multi  level  concept  which  allows  for  tailoring 
same  family  systems  from  Force  Level  Systems  to  Unit 
Level  portable  systems  through  Squadron  Level 
systems. 

2.  The  CIRCE  2001  family 

During  the  last  two  years  this  concept  has  been 
validated  through  the  delivery  to  the  French  Air  Force 
of  three  types  of  systems  belonging  to  the  CIRCE  2001 
family. 

-  SPP/PM :  Mission  Planning  and  Tasking  System,  at 
Force  Level 

-  SLPM  2000D  :  Local  Mission  Planning  System,  at 
Squadron  Level 

-  SLPM  ATT :  Dedicated  to  Hercules  and  Transall,  this 
system  include  a  portable  equipment  for  every  aircraft. 

Such  a  family  can  be  identified  by  its  common 
patrimony  as  well  as  by  the  links  between  its  members. 

-  The  CIRCE  2001  patrimony 

All  CIRCE  2001  systems  share  the  following 
patrimony : 

.  Compatible  and  modular  hardware 
.  Same  Software  open  architecture 
.  Standard  Man  Machine  Interface 
.  Functions  library 
.  Common  data  bases 
.  Homogeneous  Security  policy 

-  The  CIRCE  2001  links 

All  systems  belonging  to  this  family  are  linked  together 
by  X25  long  distance  networks  ancf  locally  througn 
Ethernet. 

Obviously  th^  also  can  be  linked  to  other  systems 
especially  at  Force  Level. 

After  this  analysis  of  the  CIRCE  2001  family  we  will 
now  describe  each  system  features. 

3.  The  family  systems 

The  three  systems  are  presented  from  the  unit  level  to 
the  force  level  system. 

-  Portable  CIRCE 

The  main  feature  of  this  system  is  its  small  scale  in 
terms  of  weight  and  volume,  this  does  not  imply  a 
proportionnal  performance  reduction.  The  major  cuts 
are  applied  to  the  peripherals  capabilities  and  the  screen 
size. 

In  addition  the  data  storage  is  limited  as  well  as  the 
number  of  available  net  work  interfaces. 

This  systems  having  been  designed  mainly  for  military 
aircraft  plans  the  two  missions  of  such  aircraft  -logistic 
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and  tactic-  and  takes  into  account  specific  requirement 
such  as  cargo  optimisation. 

Finally  the  system  loads  the  disk  which  transfers  the 
data  into  the  Flight  Management  System  and  prints  a 
flight  log. 


To  be  easily  carried  in  a  Cl 30  or  a  C160  the  SLPM 
2000D  is  made  of  ruggedized  containers.  Two  versions 
have  been  delivered  either  single  or  dual  operated 
systems.  In  the  latest  one,  each  operator  is  provided 
with  its  own  workstation,  some  peripherals  being 
shared  by  two  operators. 

The  system  is  fitted  with  significant  peripherals  such  as 
the  juke  box  in  which  is  implemented  a  huge 
geographical  data  base.  It  is  linked  to  equivalent 
systems  through  local  networks  inside  an  Air  Force 
Base  and  connected  to  the  Force  level  system  and  the 
portable  system  through  long  distance  networks. 

The  SLPM  2000  is  not  a  dedicated  system  but  a  multi 
ship  one.  It  takes  into  account,  for  each  type  of  aircraft, 
sensors  and  weapons  as  well  as  tactics  and  navigation 
modes. 

When  the  mission  planning  is  completed,  a  color 
Combat  Mission  Folder  is  printed  and  the  data 
cartridges  are  loaded. 

-LeSPP/EM 


Compared  to  local  systems  the  SPP/PM  hardware 
features  are  the  computing  power  the  network  interface 
capability  and  also  it  is  a  multioperator  system  ;  so  far 
at  the  request  of  the  French  Air  Force  three  operators  an 
working  simultaneously. 

The  SPP/PM  software  is  made  of  the  addition  of  all 
existing  local  planning  functions  and  specific  tasking 
functions.  Therefore  it  has  all  the  squadron  level 
capability  including  Combat  Mission  Folder  edition  and 
Data  transfer  Cartridge  loading.  But  its  main  feature 
consists  in  mission  tasking  which  includes  : 


a)  target  analysis, 

b)  Plan  definition  through  each  mission  basic  points 
(take  off,  target,  landing  and  plan  parameters, 

c)  global  optimization  of  trajectors  taking  into  account, 

-  aircraft  data  (consumption,  weapons,  navigation) 

-  geographical  data 

-  tactical  situation 

d)  Chronology, 

e)  Deconfliction  :  conflicts  identification  and  automated 
deconfliction. 

4.  Current  trends 

Some  trends  are  currently  identified  that  could  be  taken 
into  account  for  future  systems  design  as  well  as  for 
existing  systems  improvment. 

At  the  squadron  level  the  link  between  postflight 
debrief  (damage  assessment  and  tactical  situation 
imdate)  and  mission  planning  is  yet  clearly  identified. 
Tne  emerging  Part  Task  Trainers  could  also  be  linked 
to  the  squadron  level  mission  planning  systems  and 
even  share  hardware  components  such  as  CPU, 
software  functions  such  as  3D  rehearsal,  tactical  and 
geographical  data. 

At  the  Force  Level  it  should  be  under  lined  that  the 
system  capabilities  described  previously  (plan 
definition,  global  optimization,  chronology, 
deconfliction)  are  very  close  to  an  automated  Air 
Tasking  order  generator.  Therefore  it  would  make  sense 
to  integrate  the  Air  Tasking  Order  generation  and 
despatching  into  the  mission  tasking  and  planning 
system  in  stead  of  having  a  separate  aso  dedicated 
system. 
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1.  SUMMARY 

A  Decision  Tool  for  air  defence  is 
presented.  This  Decision  Tool, 
when  provided  with  information 
about  the  radar,  the  environment, 
and  the  expected  class  of  targets, 
informs  the  radar  operator  about 
detection  probabilities.  This 
assists  the  radar  operator  to  select  the  optimum  radar  parame¬ 
ters.  In  the  future,  a  Decision  Tool  will  be  developed  that 
advises  the  radar  operator  about  the  optimum  selection  of 
radar  parameters. 

2.  INTRODUCTION 

In  many  cases,  a  radar  operator  has  more  than  one  radar 
system  at  his  disposal  in  order  to  search  for  approaching 
targets.  These  systems  may  differ  largely  with  respect  to 
transmitted  power,  antenna  gain,  frequency,  polarization,  noise 
figure  and  signal  processing.  Further,  for  each  radar  system, 
the  operator  can  choose  some  parameters  like  pulse  repetition 
frequency,  pulse  length,  frame  time,  etc.  Which  radar  system 
and  which  set  of  parameters  will  yield  the  largest  possibility  of 
detection  depends  heavily  on  the  actual  propagation  condi¬ 
tions  (ducting!),  on  the  target  that  is  expected  (altitude, 
velocity),  and  on  the  clutter  from  the  environment. 

TNO-FEL  has  developed  a  computer  program  called 
PARADE  that,  provided  with  a  set  of  radar  parameters  and 
actual  meteorological  conditions,  calculates  radar  coverage 
diagrams  as  a  function  of  range  and  altitude.  The  program  can 
also  compute  detection  probabilities  as  a  function  of  range  and 
altitude  for  a  given  target  radar  cross  section  and  velocity.  It  is 
based  on  the  program  described  in  [1].  Some  examples  will  be 
shown,  displaying  the  capabilities  of  PARADE.  PARADE  is 
currently  being  extended  to  a  Decision  Tool,  which  can  advise 
the  operator  which  radar  system  to  use  and  which  parameters 
to  select. 

3.  DECISION  TOOL 

As  has  been  pointed  out  in  the  introduction,  the  performance 
of  a  radar  system  depends  not  only  on  the  set  of  parameters 
chosen  by  the  radar  operator,  but  also  on  the  environmental, 
conditions  and  on  the  class  of  targets  that  is  expected. 


Fig.  1:  Multipath. 

radar  to  the  target  follow  several  paths:  the  direct  path,  and 
one  or  more  paths  via  the  ground  or  via  obstacles  (Fig.  1). 
Arriving  at  the  target,  these  signals  interfere  with  each  other, 
resulting  in  either  increased  or  decreased  total  signal  strength. 
Whether  ducting  occurs  depends  on  the  way  the  index  of 
refraction  n  of  the  atmosphere  changes  with  altitude  h.  This  in 
turn  depends  on  the  temperature  profile,  the  relative  humidity 
and  the  wind  speed.  Whether  ducting  occurs  can  be  deter¬ 
mined  easily  from  the  dependence  of  the  modified  refractivity 
M  with  altitude.  The  modified  refractivity  is  defined  as 

M(h)  =  (n  -  1  +  h/a)xI0®  , 

where  a  is  the  radius  of  the  earth.  When  there  is  a  layer  in  the 
atmosphere  in  which  M  decreases  with  increasing  altitude, 
ducting  occurs,  and  part  of  the  radar  signal  is  trapped  in  the 
duct.  Four  types  of  duct  are  illustrated  in  figure  3. 

Apart  from  trapping,  superrefraction,  subrefraction  or  standard 
propagation  may  occur  (Fig.  2),  depending  on  the  exact 
meteorological  conditions  that  determine  the  refractivity 
profile. 


Among  the  environmental  conditions  that  influence  the  radar  |  _ 

performance  are  multipath  and  ducting.  Multipath  is  the  well- 

known  phenomenon  that  the  radar  signals  travelling  from  the  Fig.  2:  Wave  paths  for  various  refractivity  conditions. 

Paper  presented  at  the  AGARD  MSP  3rd  Symposium  on  "Tactical  Aerospace  C^I  in  Coming  Years”, 
held  in  Lisbon,  Portugal  from  15th  May  to  18th  May  1995,  and  published  in  CP-557. 
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a.  Surface  duct  formed  by  a  surface  trapping  layer. 


b.  Surface-based  duct  formed  by  an  elevated  trapping 
layer. 


c.  Elevated  duct  formed  by  an  elevated  trapping  layer. 


d.  Evaporation  duct  formed  by  a  decrease  of  humidity 
immediately  adjacent  to  the  sea  surface. 

Fig.  3:  Examples  of  atmospheric  ducts. 


The  combination  of  multipath  and  duct  may  give  rise  to  very 
complicated  propagation  paths.  In  figure  4  a  so-called 
“coverage  diagram”  is  presented  for  an  evaporation  duct 
height  of  20  m.  The  radar  frequency  is  16  GHz  and  the 
antenna  is  located  at  an  altitude  of  8  m  and  has  an  elevation  of 
zero  degrees.  Note  that  the  path  loss  is  very  large  at  altitudes 
of  3  to  4  m  for  all  ranges  except  the  very  short  distances.  This 
means  that  a  low  flying  missile  can  approach  the  platform 
without  being  detected  when  a  frequency  of  16  GHz  has  been 
chosen  for  surveillance  under  these  circumstances.  Obviously, 
when  the  radar  operator  has  a  Decision  Tool  available  that 
informs  him  about  the  actual  radar  coverage,  he  will  not  stick 
to  this  frequency.  More  information  about  propagation  can  be 
obtained  from  [2,3,4]. 

Apart  from  the  transmitter  frequency  of  the  radar,  there  are 
other  radar  parameters  that  have  a  significant  influence  on  the 
detection  probabilities.  The  pulse  repetition  frequency  (PRF) 
of  the  radar  introduces  so-called  blind  ranges  and  blind 
velocities  [5],  as  is  illustrated  in  the  “blind  zone  diagram”  of 
figure  5. 

Blind  ranges  occur  because,  at  the  moments  the  radar  is 
transmitting  a  pulse,  the  reception  of  echoes  from  previous 
pulses  is  not  possible.  The  time  between  two  pulses  is  1/PRF, 
in  which  PRF  is  the  pulse  repetition  frequency,  which  is  often 
in  the  order  of  kHz  or  tens  of  kHz.  Therefore,  for  targets  at 
distances  that  are  integer  multiples  of  c/(2xPRF),  in  which  c  is 
the  speed  of  light,  the  possibility  of  detection  is  zero.  In 
figure  5,  the  PRF  is  5  kHz,  and  hence  the  blind  ranges  occur 
every  30  km. 

Blind  speeds  occur  because  the  clutter  spectrum,  which  has  a 
peak  at  a  Doppler  frequency  of  zero,  repeats  itself  with  a 
period  equal  to  the  pulse  repetition  frequency.  As  a  conse¬ 
quence,  when  the  Doppler  frequency  shift  of  a  target  is  an 
integer  multiple  of  the  PRF,  the  target  return  has  to  compete 
with  the  ground  clutter.  Hence,  when  the  target  velocity  is  an 
integer  multiple  of  A,xPRF/2,  in  which  X  is  the  wavelength,  the 
possibility  of  detection  is  reduced.  In  figure  5,  the  wavelength 
is  0.03  m,  and  hence  the  first  blind  velocity  occurs  for  a  target 
velocity  of  75  m/s. 

In  order  to  optimize  the  possibility  of  detection  for  a  certain 
class  of  targets,  it  is  obviously  important  to  choose  the  PRF 
with  care,  or  to  vary  the  PRF  regularly.  The  regular  variation 
of  the  PRF  is  called  staggering.  The  Decision  Tool  can  assist 
the  radar  operator  to  make  the  right  selection. 

Apart  from  multipath,  ducting,  blind  ranges,  blind  velocities, 
and  clutter,  also  hostile  jammers  often  pose  a  problem  to  the 
radar  operator.  The  Decision  Tool  is  able  to  predict  the 
reduced  detection  probabilities  in  certain  angular  sectors  when 
a  jammer  is  present.  This  is  illustrated  in  figure  6,  where  a 
scenario  with  three  jammers  has  been  chosen. 

4.  FUTURE  DEVELOPMENTS 

In  the  previous  section,  we  have  discussed  a  Decision  Tool 
that  informs  the  radar  operator  about  detection  probabilities, 
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Range  (km) 


Frequency  16  GHZj  Duct  height  20  n. 


Fig.  4:  Coverage  diagram.  Evaporation  duct  height  20  m,  transmitter  frequency  16  Ghz. 


Fig.  5:  Blind  zone  diagram.  PRF  =  5  kHz. 
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Fig.  6:  Horizontal  coverage  diagram  for  a  scenario  with  three  jammers. 


based  on  the  selected  radar  parameters,  the  environmental 
conditions,  the  presence  of  jammers  and  the  class  of  targets 
expected.  When  the  operator  wants  to  obtain  the  optimum 
radar  parameters,  he  has  to  try  out  many  possibilities.  Often, 
he  does  not  have  the  time  for  this.  Therefore,  we  intend  to 
modify  the  Decision  Tool,  in  such  a  way  that  it  is  capable  to 
advise  the  operator  about  which  parameters  to  select,  or,  when 
applicable,  to  advise  how  to  stagger  several  parameter  values. 
As  the  Decision  Tool  is  computationally  intensive,  parallel 
processing  will  be  needed. 

Further,  it  is  our  intention  to  increase  the  applicability  of  the 
Decision  Tool.  For  instance,  we  wish  to  incorporate  a  more 
advanced  propagation  model  in  order  to  be  able  to  calculate 
propagation  over  rough  seas  and  over  terrain  with  hills,  cliffs 
and  buildings.  A  possible  model  for  this  is  given  in  [6].  Of 
course,  in  this  case  we  will  also  need  a  more  sophisticated 
clutter  model  to  calculate  the  clutter  returns  from  terrain. 
Another  application  for  which  we  will  need  a  more  sophisti¬ 
cated  clutter  model  is  high-resolution  radar.  When  radar  pulses 
are  very  short,  the  clutter  becomes  very  spiky,  so  that,  for  a 
certain  average  clutter  level,  false  alarms  can  occur  more 
often. 

Last  but  not  least,  we  wish  to  incorporate  models  for  infrared 
systems  in  the  Decision  Tool,  as  infrared  systems  and  radars 
can  be  complementary.  An  operational  range  prediction  model 
for  infrared  search  and  track  systems  is  presented  in  [7].  When 
the  radar  has  a  reduced  coverage  in  a  certain  sector,  because  of 
the  propagation  conditions,  the  background  clutter  or  jam¬ 
mers,  the  Decision  Tool  may  advise  to  rely  more  on  an 
infrared  system  in  this  sector.  On  the  other  hand,  when  the 
infrared  system  has  a  reduced  coverage  in  a  certain  sector 
because  of  background  radiation  or  aerosols,  the  Decision 
Tool  can  advise  to  rely  more  on  the  radar  in  this  sector.  For  an 
optimum  use  of  the  time  budget  of  the  search  systems,  the 
Decision  Tool  can  allocate  certain  sectors  of  the  search 
volume  to  the  radar  and  other  sectors  to  the  infrared  system. 


5.  CONCLUSION 

We  have  presented  a  Decision  Tool  that  assists  radar  operators 
to  select  the  optimum  radar  parameters  for  air  defence,  given 
the  radar  systems  available,  the  environmental  conditions  and 
the  class  of  targets  that  is  expected.  Some  future  developments 
have  been  discussed.  The  Decision  Tool  is  expected  to  be  a 
very  powerful  aid  for  both  radar  operators  and  commanders, 
and  is  expected  to  increase  platform  survivability. 
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1.  SUMMARY 

Adaptive  strike  missiles  have  the  capability  to 
autonomously  find  and  attack  targets.  In  many 
cases,  the  location  of  the  target  is  not  known, 
and  the  missile  must  perform  a  search  of  the 
region  in  order  to  detect  any  existing  targets. 
This  search  entails  the  planning  of  a  search  flight 
path,  tailored  to  the  sensor’s  capabilities,  that 
will  maximize  the  probability  of  detection. 

The  Search  Planner  is  composed  of  a  search  path 
subsystem  that  includes:  1)  a  tactical  motion 
analyzer  that  takes  into  account  terrain  and  feature 
data,  and  determines  a  probable  search  region 
based  on  the  motion  capability  of  the  target;  2)  a 
feature  extractor  subsystem  which  generates 
most-likelihood  feature  maps,  such  as  tree-lines, 
that  govern  possible  target  locations  within  the 
critical  region;  3)  a  path  generator  subsystem 
that  determines  the  best  search  path  by  first 


covering  the  possible  target  locations  with 
rectangular  strips  and  then  chaining  them 
together  in  a  near-optimal  way;  and  4)  a  sensor 
manager  that  optimizes  allocation  of  sensor 
resources  as  the  missile  travels  through  the 
search  region. 

To  validate  our  concept,  we  have  integrated  the 
Search  Planner  into  a  many-on-many  simulator 
that  functions  to  optimally  allocate  a  missile 
strike  force  en-route.  This  paper  describes  the 
design  of  the  Search  Path  Planner  subsystem 
which  consists  of  a  Search  Area  Generator,  a 
Segment  Generator,  a  Link  Generator,  and  a  Link 
Chainer  module. 

2.  APPROACH  AND  RESULTS 

The  following  figures  (1  through  16)  illustrate 
the  overall  concept,  its  sub-systems,  the 
algorithms,  and  results  of  a  simple  example. 


•Missile  able  to  Re-Plan  In  Response  to  Changing  Conditions 

-Use  Established  Mission  Pianning  Concepts 
-Communicate  with  Other  Missiies  in  Flight 
-Pian  New  Optimal  Routes 
-Optimally  Allocate  Itself 
-Optimally  Search  Uncertainty  Regions 
-Perform  In-Flight  Weaponeering 
-Assess  Target  Vaiidity 


Figure  1 .  The  concept  is  for  an  autonomous  missiie  to  be  able  to  re-plan  its  mission  in  response 
to  changing  conditions  in  the  environment.  This  system  must  be  able  to  (1)  Communicate  with 
other  missiies  such  that  each  individuai  missile  has  knowledge  of  how  it  fits  into  the  mission;  (2) 
Plan  new  optimal  routes;  (3)  Optimally  allocate  itself  to  a  target  within  the  battle  scenario;  (4) 
Assess  the  validity  of  a  given  target  via  Automatic  Target  Recognition. 


(Route  Planner) 

(Strike  Planner) 

(Search  Path  Planner) 
(Terminal  Area  Planner) 

(Target  Recognition  Processor) 


Paper  presented  at  the  AGARD  MSP  3rd  Symposium  on  “Tactical  Aerospace  OI  in  Coming  Years", 
held  in  Lisbon,  Portugal  from  15th  May  to  1 8th  May  1995,  and  published  in  CP-557. 
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Figure  2.  Missiles  are  used  to  attack  both  fixed  targets  and  area  targets.  There  are  two  types  of 
area  targets:  (1)  Mobile  targets  that  have  moved  from  known  positions  as  originally  determined  by 
reconnaissance;  2)  Targets  in  uncertainty  regions  where  the  presence  of  targets  is  unknown. 


Search  Path  Planner:  Requirements 

•  Area  Search: 

-  Search  Arbitrarily  Shaped  Areas  for  Targets 

-  Optimize  Search  If  Given 

»  Feature  Data 
»  Rules-of-Thumb 

•  Likely  Areas 

•  Direction  of  Search 

•  Relocatable  Targets: 

-  Search  Area  for  Specific  Target 

-  Optimize  Search  If  Given 

»  TMA  Information 
»  Feature  Data 
»  Rules-of-Thumb 

•  Likely  Areas 

•  Direction  of  Search 


Figure  3.  (1)  Area  Search  occurs  when  we  plan  to  search  an  arbitrarily  shaped  area  for  targets, 
and  the  targets  have  not  been  localized.  (2)  Re-locatable  target  Search  occurs  when  a  localized 
target  is  capable  of  movement  while  the  weapon  is  en-route.  The  Tactical  Movement  Analyzer 
developed  at  Jet  Propulsion  Laboratory  (JPL)  is  used  to  estimate  the  outer  bound  of  the  area,  as 
a  function  of  time,  that  will  contain  the  mobile  target. 
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Map  Definitions 


Scenario  Area 


Scenario  Area: 

Area  in  which  the  mission  is  confined 

Target  Area: 

Maximum  area  in  which  to  search 
Search  Area: 

Area  actually  searched 

Target  Location: 

Fixed  target  location 

S _ _ _ d 

X 

Target  Location 

Target  Location 

Target  Area 

□ 

Target  Area 

□ 

Figure  4:  The  Scenario  Area  is  the  area  in  which  the  whole  mission  will  be  contained.  The 
weapons  will  never  fly  outside  of  the  scenario  area.  The  Target  Area  is  the  maximum  area  that  will 
be  searched.  If  we  have  information  as  to  the  terrain  and  the  mobile  target  movement  capabilities, 
we  can  use  this  information  to  reduce  the  size  of  Target  Area  to  a  smaller  region  called  the  Search 
Area.  The  Search  Area  is  the  area  that  the  missile  will  actually  search.  The  Target  Locations  are 
simply  the  locations  of  fixed  targets. 


Figure  5;  The  first  step  is  to  define  the  search  area.  If  there  is  information  available  that  can 
narrow  the  search  to  more  likely  areas  (within  the  target  area)  we  will  exploit  this  information.  Such 
information  includes  the  vehicle's  ability  to  traverse  terrain,  and  the  elapsed  time  since  the  target 
was  last  sighted.  We  can  further  reduce  the  search  area  by  exploring  high  probability  features 
such  as  roads,  tree  lines,  railways,  etc.,  and  de-emphasizing  low  priority  features  such  as  lakes, 
swamps,  and  mountainsides.  The  second  step  is  to  generate  the  search  segments.  These  are 
the  search  swaths  used  to  cover  the  search  area.  The  third  step  is  to  generate  the  segment  links. 
These  are  the  flight  paths  from  the  exit  points  of  one  search  segment  to  the  entrance  points  of 
the  next  search  segment.  The  fourth  step  is  to  chain  the  segments  and  select  the  optimal  or  near- 
optimal  chain. 
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1 :  Generate  the  Search  Area 


•  Tactical  Movement  Analyzer  defines  the  Search  Area 
•  How  far  can  the  target  move  in  a  given  time 
•Terrain 

•Vehicie  capabilities 


Figure  6:  A  system  called  the  Tactical  Movement  Analyzer  (TMA)  developed  by  Jet  Propulsion 
Laboratories  is  used  to  generate  the  search  area.  The  Tactical  Movement  Analyzer  estimates  the 
area  that  wouid  contain  the  target  after  a  fixed  amount  of  time.  It  takes  into  account  the  type  of 
terrain,  features,  weather  and  the  vehicie's  ability  to  traverse  that  terrain.  The  output  from  the  TMA 
is  a  set  of  points  which  is  input  to  the  Search  Area  Segmenter. 


2:  SEARCH  AREA  SEGMENTER 


OBJECTIVE: 

Cover  at  least  95%  of  a  prescribed  set  of  N  planar  points  with 
a  minimum  number  of  rectangular  strips  of  width  W  and 
unrestricted  length. 


INPUT: 

N  coordinate  pairs  [  Search  Area  ],  and  strip  width  W. 
OUTPUT: 

Corners  of  covering  strips  of  width  W. 


Figure  7:  The  objective  of  the  Search  Area  Segmenter  is  to  obtain  a  minimum  number  of 
rectangular  strips  of  width  W  and  unrestricted  iength.  These  rectanguiar  strips  will  cover  at  least 
95%  of  a  prescribed  set  of  points  which  represent  the  probable  locations  of  targets.  This  vaiue, 
95%,  is  a  user  selected  parameter  and  is  used  to  adjust  for  the  significant  effect  the  last  few 
percent  can  have  on  the  total  flight  distance.  The  input  to  this  subsystem  is  a  binary  (1,0)  grid  map 
of  the  search  area,  where  the  1’s  represent  search  points  and  the  O’s  represent  non-interest 
points.  The  search  width  is  also  specified  and  is  a  function  of  the  missile  flight  altitude  and  the 
seeker  field-of-view.  The  output  of  this  subsystem  is  a  set  of  four-corners  of  the  covering  strips. 
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Figure  8:  An  example  of  the  function  of  this  Search  Area  Segmenter  is  as  follows.  The  probable 
target  locations  are  indicated  by  the  1's  in  the  figure.  The  desired  output  of  the  Search  Area 
Segmenter  is  three  rectangular  strips  that  cover  the  three  limbs. 


APPROACH: 

Uni-directional  coverings  [  lawnmowers  ] 
These  are  coverings  by  parallel  strips. 

Multi-directionai  coverings. 

MAJOR  TASKS: 

Determine  desirable  strip  directions. 

Given  directions,  determine  covering  strips. 


Figure  9:  For  the  Search  Area  Segmenter,  the  approach  we  have  taken  is  to  divide  the  problem 
into  two  categories.  If  the  search  area  can  be  covered  by  a  number  of  parallel  strips,  then  we  will 
use  a  “lawnmowef”  coverage.  Otherwise,  we  will  use  a  multi-directional  covering  scheme  where 
the  strips  are  generally  non-parallel.  The  tasks  are  to  determine  the  desirable  strip  directions,  and 
given  these  directions,  determine  the  covering  strips. 
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DIRECTIONS 

STRIPS 
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hull  facets 

linear  K-cover 

MULTI-DIRECTIONAL 

boundary 

best-first 
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Figure  10:  For  the  first  case  of  “lawnmower”  coverage,  the  desirable  direction  is  determined  by 
the  dominant  direction  of  the  convex  hull  facets.  The  Graham  Scan  algorithm  is  used  to  determine 
the  convex  hull  and  the  “caliper  algorithm  is  used  to  obtain  a  rectangular  directional  hull. 
Determination  of  strips  which  are  placed  over  a  directional  hull  is  then  reduced  to  a  linear  K-cover 
problem.  If  a  multi-directional  coverage  is  desired,  we  use  a  boundary  histogramming  approach  to 
iteratively  obtain  the  segment  directions.  The  strips  are  then  determined  by  a  best-first,  or, 
“greedy”  algorithm. 


FUNDAMENTAL  FACT: 

For  a  fixed  direction,  covering  pianar  points  by  strips  reduces  to 
covering  linear  points  by  intervals. 

This  reduces  the  2-dimensional  problem  to  the  line. 

RESULTING  METHOD: 

For  fixed  direction  DIR,  project  the  Search  Area  onto  the  line  normal  to  DIR. 
Now  cover  the  linear  point  set  with  intervals. 


Figure  11:  In  the  "lawnmower"  coverage  mode  (fixed  direction),  covering  planar  points  by 
strips  reduces  to  covering  linear  points  by  intervals.  This  reduces  the  2-dimensional  problem  to  a 
1 -dimensional  problem.  An  example  of  the  technique  follows. 


SEARCH  AREA,  N  =  20 
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Figure  12:  The  20  crosses  (x)  in  the  upper  portion  of  the  figure  are  to  be  covered  by  vertical 
strips  in  the  “lawnmower"  scheme.  The  orthogonal  or  perpendicular  direction  to  the  strip  direction 
is  therefore  "horizontal".  This  technique  reduces  the  2-dimensional  problem  to  a  1 -dimensional 
problem,  and  is  performed  by  projecting  all  the  crosses  (x)  to  a  horizontal  line  (orthogonal  or 
perpendicular)  to  the  direction  of  the  strips  which  are  vertical  in  this  example.  These  multiplicity 
numbers  on  the  horizontal  line  represent  the  number  of  crosses  covered  by  a  vertical  strip  at  that 
position.  For  instance,  80%  of  the  crosses  are  covered  by  4  vertical  strips  of  width  2. 

3:  GENERATION  OF  LINKS  BETWEEN  SEGMENTS 


Turn  Radius  Constrained  Exit  /  Entrance  Circles 


Figure  13:  Once  the  rectangular  segments  are  determined,  their  coordinates  are  sent  to  the 
Segment  Linker  function  which  generates  fiight  paths  between  segments.  The  fiight  dynamics  of 
the  platform  are  accommodated  by  including  the  turn  radius  as  an  input  to  the  process  of 
generating  the  set  of  ali  possibie  iinks  between  search  segments.  In  the  example,  two  segments 
are  shown  and  we  wish  to  exit  the  top  segment  from  its  right  side  and  enter  the  lower  segment 
from  its  right  side  too.  The  maximum  "g"  turn  radius  circles  are  shown  at  the  exit  and  entrance 
points. 


Figure  14:  Shown  here  are  examples  of  two  flight  paths  that  might  be  used  to  join  segment 
ends  that  are  closer  than  two  turn  circle  radii.  Simple  geometric  algorithms  and  logic  discriminates 
are  applied  to  determine  the  flight  path  between  segments  within  the  Segment  Linker  function. 
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4:  SEGMENT  CHAINER  FUNCTION 


CHAINER  SEARCH  METHODS: 

•  EXHAUSTIVE  SEARCH 

•  BEST  FIRST 

•  SIMULATED  ANNEALING 

•  HEURISTIC  APPROACH 

•  NEURAL  NET 


I  Segment  7  "1  - 


Segment  5 
Segment  4 


Segment  6 


Segment  3 
Segment  2 


Figure  15:  Once  we  have  calculated  the  set  of  all  segment  links,  we  must  chain  them  together 
into  a  single,  near-optimal,  flight  path.  The  idea  is  to  chose  a  method  or  combination  of  methods 
that  will  give  a  solution  to  this  "assignment"  problem  in  a  timely  manner.  In  addition,  system 
memory  constraints  must  be  taken  into  account.  In  this  example,  there  are  seven  segments  which 
implies  that  there  are  3840  possible  flight  paths  between  the  exit  point  of  segment  one  and  the 
exit  point  of  segment  seven.  One  path  is  desired  and  is  determined  by  the  Segment  Chainer. 


Search  Path  Planner:  Segment  Chainer 
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Figure  16:  Jet  Propulsion  Laboratory  (JPL)  has  provided  us  with  a  neural  net  solution  which 
allows  for  adjustable,  multiple,  assignments  based  on  system  constraints.  Using  this  approach, 
we  construct  a  cost  matrix  according  to  our  constraints,  and  input  this  matrix  to  the  neural  net.  This 
neural  net  then  generates  the  solution  matrix.  This  solution  matrix  provides  our  assignments, 
which  links  our  segments  to  form  a  near-optimal  or  optimal  pathway. 
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Une  demarche  pour  un  atelier  de  production  de  C3I  oriente  Simulation 
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1 .  Le  probleme 


1. 1  Les  decisions  et  ies  couts 

Le  deroulement  d’un  programme  de  quelque  importance 
pose  un  probleme  majeur  lie  a  sa  duree  :  pour  des  raisons 
d’homogeneite  et  de  facilite  de  controle,  les  decisions 
majeures  en  termes  d’ architecture  soiit  prises  tres  en 
amont.  L’avantage  est  que  le  cout  du  programme  est  assez 
vite  fixe  (en  termes  de  cout  previsionnel),  I’inconvenient 
est  que  le  cout  du  programme  est  imprevisible  (en  termes 
de  cout  reel). 

En  effet  d’une  part  le  besoin  a  Torigine  du  programme 
evolue  (choix  entre  resultat  inutile  et  revision  dechirante), 
d’autre  part  le  progres  technologique  est  a  prendre  en 
compte  (choix  entre  resultat  obsolete  et  refonte 
architecturale). 

L’interet  du  responsable  de  programme  est  de  prendre  le 
plus  tard  possible  les  decisions  de  conception,  ou  au  moins 
de  les  etaler  au  maximum.  Nous  montrerons  que  la 
simulation  est  en  ce  sens  une  aide  puissante. 

1.2  De  queiie  simuiation  parions-nous  ? 

En  gros,  simuler,  c’est  substituer  a  un  systeme  un  autre 
plus  simple  capable  de  mimer  son  comportement  externe 
avec  un  niveau  de  detail  et  un  niveau  de  vraisemblance 
donnes. 

Cette  definition  naive  foumit  un  axe  de  classification  (un 
seul,  car  finesse  et  vraisemblance  sont  tres  liees).  On 
simplifiera  encore  en  ne  retenant  que  trois  points  : 

-  Simulation  technico-operationnelle  :  niveau  grossier, 
vraisemblance  limitee  aux  generalites  fonctionnelles. 
Les  modeles  sont  simples  et  ne  permettent 
generalement  pas  une  representation  fidele  (interaction 
humaine  exclue),  mais  executables  rapidement :  on 


pent  simuler  un  grand  nombre  d’acteurs,  de 
nombreuses  fois  (Monte  Carlo).  Non  temps-reel,  ce 
niveau  est  adapte  aux  etudes  parametriques  a  grande 
echelle  (concepts,  doctrine,  validation  de  besoin). 

-  Jeu  de  guerre  :  niveau  juste  assez  fin  pour  rendre 
possible  rinteraction  humaine,  au  moins  par  moments. 
Les  modMes  etant  plus  complexes,  le  nombre  d’acteurs 
possibles  est  restreint.  Eventuellement  temps  reel,  ce 
niveau  est  celui  de  Tetude  et  de  la  validation  tactiques. 

-  Simulateur  :  C’est  le  niveau  de  detail  maximum.  Sa 
complexite  le  limite  a  un  systeme  unique, 
I’environnement  pouvant  etre  simule  ou  non. 

L’interface  entre  le  systeme  simule  et  le  monde  reel 
(operateurs  inclus)  est  reproduite  dans  ses  moindres 
details. 

Nous  laissons  volontairement  de  cote  les  simulateurs 
d’entrainement  qui  se  situent  quelque  part  entre  les  deux 
demiers  niveaux  mais  sont  hors  de  notre  propos. 

1.3  La  place  de  Voperateur  humain 

Selon  le  niveau  etudie,  I’operateur  humain  va  etre  pris  en 
compte  soit  de  maniere  virtuelle  sous  forme  d’un  modele 
simple,  voire  simpliste  (simulation  technico- 
operationnelle),  soit  en  devenant  un  acteur  dont  les  actions 
auront  une  incidence  plus  ou  moins  preponderante  sur  le 
deroulement  de  la  simulation  (jeu  de  guerre  ou  simulateur). 
La  definition  du  modele  pour  integration  a  la  simulation 
technico-operationnelle  suppose  de  caracteriser  des 
comportements  attendus  proches  de  ceux  observes  dans  des 
situations  analogues. 

La  presence  de  Thomme  dans  la  boucle  de 
fonctionnement  des  jeux  de  guerre  et  encore  plus  des 
simulateurs  apporte  un  element  primordial  par  son 
interaction  en  temps  reel  sur  les  processus  de 
fonctionnement  du  systeme.  Elle  impose  par  contre  de 
repondre  de  maniere  adequate  aux  contraintes  inherentes  a 
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la  presence  humaine.  Ces  contraintes  peuvent  se  classer  en 
quatre  grandes  categories  : 

-  contraintes  d’ordre  sensori-moteur,  en  fonction  de 
Torganisation  physique  du  poste  d’activite  :  il  est 
souvent  necessaire  de  concevoir  des  postes  cote  a  cote, 
avec  ecrans  couleur  et  IHM  reconfigurables,  afin  de 
faciliter  la  realisation  de  taches  concertees  et  de 
minimiser  les  risques  d’erreurs, 

-  contraintes  de  type  neurophysiologique  liees  a  la  duree 
et  a  Torganisation  des  services  ainsi  qu’a  la  monotonie 
ou  a  la  surcharge  de  travail  pour  certaines  periodes 
d’activite  :  le  recours  a  des  taches  transferables  est  alors 
a  envisager, 

-  contraintes  de  nature  cognitive,  au  niveau  de  la 
representation  mentale  que  les  operateurs  se  feront  du 
systeme,  et  plus  particulierement  du  fonctionnement 
des  automates :  des  aides  et  des  assistances  sont  a 
prevoir  et  a  evaluer  sur  simulateur  afin  d’apprehender 
les  delais  necessaires  a  une  prise  de  decision  lors  de 
situations  complexes  et  critiques, 

-  contraintes  de  formation  et  d’entrainement  des 
personnels  concernes. 

D’une  maniere  generale  les  taches  incombant  a 
I’optoteur  humain  peuvent  concerner  ; 

-  la  surveillance  courante  de  la  situation, 

-  I’optimisation  de  la  visualisation  de  cette  situation, 

-  la  supervision  du  fonctionnement  de  processus 
automatiques, 

-  r  intervention  en  cas  de  doute  sur  le  fonctionnement, 

-  le  recueil  de  renseignements  et  d’ informations 
caracterisant  un  evenement, 

-  le  besoin  d’anticiper  en  fonction  de  revolution  de  la 
situation, 

-  la  gestion  des  moyens  de  communication, 

-  le  controle  de  I’etat  des  equipements, 

-  la  compensation  d’automatismes  en  cas  de  panne, 

-  r optimisation  de  T utilisation  des  differents 
equipements. 

Get  ensemble  de  taches  implique  de  : 

-  privilegier  le  principe  d’un  affichage  minimal  des 
informations  selon  le  contexte  du  moment, 


-  preserver  la  comprehension  par  I’operateur  humain  de 
I’etat  de  fonctionnement  pendant  les  phases  de  faible 
activite  (surveillance), 

-  ofifrir  des  possibilites  d’ anticipation  avant  et  en  cours  de 
situations  critiques. 


2.  Simulation  d’un  C3I 

Nous  nous  interessons  ici  aux  functions  principales 
impliquees  par  I’acronyme : 

-  Commandement  et  controle, 

-  Communication, 

-  Renseignement. 

2. 1  Systeme  a  logiciel  preponderant 

Un  C3I  est  avant  tout  une  machine  a  acquerir,  filtrer, 
presenter  et  diffuser  I’information.  Son  comportement  est 
entierement  decrit  par  du  logiciel.  L’aspect  materiel,  bien 
que  non  marginal  (C3I  embarques  en  particulier, 
dispositifs  de  communication  en  general),  n’est  pas 
preponderant  dans  la  recherche  de  satisfaction  du  besoin. 

On  pent  repartir  grossierement  les  services  logiciels  selon 
les  functions  : 

-  Commandement  et  controle  :  filtrage  contextuel, 
presentation  et  aide  a  la  decision,  cartographic. 

-  Communication  :  gestion  de  reseau,  filtrage  securitaire, 
ciyptage. 

-  Renseignement :  traitements  divers  (imagerie),  fusion, 
presentation,  cartographic. 

Cette  repartition  n’est  pas  exhaustive. 

Simuler  un  C3I,  c’est  en  fait  realiser  un  logiciel  plus 
simple  que  le  logiciel  du  systeme  reel.  Rien  n’interdit  a  une 
simulation  bien  construite  d’evoluer  peu  a  peu  vers  un 
logiciel  operationnel.  Le  mot  cle  est  bien  construit. 

2.2  Systeme  d'aide  a  la  decision  et  facteur 
humain 

Le  point  cle  a  resoudre  consiste  a  faciliter  la 
comprehension  de  la  situation  en  apportant  des 
informations  coherentes  en  regard  de  la  representation 
mentale  de  I’operateur. 

La  difficulte  reside  bien  souvent  dans  le  fait  que  I’homme 
et  le  systeme  n’ont  pas  les  memes  attributions  ni  les  memes 
modalites  de  fonctionnement. 
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Les  taches  dites  fermees,  c’est-a-dire  dont  les  objectifs 
restent  identiques  a  chaque  realisation  de  la  tache,  sont 
confiees  an  systeme;  pour  chaque  realisation,  les 
parametres  demeurent  en  general  peu  fluctuants  et 
predictibles. 

Les  taches  dites  ouvertes,  dont  le  mode  operatoire  est 
propre  a  chaque  realisation  de  la  tache,  incombent  par 
centre  a  Thomme.  II  doit  done  decider  du  cheminement 
satisfaisant  en  fonction  du  contexte  du  moment,  avec  une 
assistance  eventuelle  par  un  ou  des  automates  plus  ou 
moins  evolues,  sur  lesquels  il  pourra  agir  en  termes 
d’initialisation,  de  parametrage  et  de  controle.  Toutefois 
les  actions  seront  dependantes  du  type  d’automates,  ceux-ci 
se  classant  en  trois  grandes  categories  : 

-  automates  sans  intervention  humaine  sur  les  resultats 
des  traitements, 

-  automates  dont  les  sorties  peuvent  etre  modifiees  par 
I’operateur, 

-  automates  qui  suggerent  des  choix,  I’operateur  devant 
choisir  pour  valider  ou  rejeter  la  ou  les  solutions 
proposees. 

Ces  categories  peuvent  elles-memes  se  scinder  en  deux 
sous  categories  : 

-  automates  figes,  dont  les  parametres  de  fonctionnement 
sont  predetermines  et  non  modifiables  par  I’operateur. 

»  automates  contraints,  ou  les  parametres  ont  ete  definis  a 
priori  mais  ou  Foperateur  peut  modifier  les  valeurs 
d’entree  selon  le  contexte. 

On  peut  ainsi  aboutir  a  un  ensemble  tres  complexe  selon 
la  nature  des  automates  en  fonctionnement  et  de 
Finteraction  avec  Foperateur.  II  est  egalement  important 
de  noter  que  le  degre  d’ experience  de  Foperateur  va  jouer 
un  role  primordial.  II  apparait  que  les  operateurs  les  plus 
experimentes  tirent  generalement  les  plus  de  benefice  des 
assistances  apportees  par  les  automates.  De  par 
Fexperience  qu’ils  possedent,  ils  sont  mieux  a  meme  de 
comprendre  et  d’utiliser  les  recommandations  ou  les 
solutions  proposees,  meme  si  elles  ne  correspondent  pas 
entierement  a  ce  qu’ils  attendent  du  fait  justement  de  leur 
experience.  Les  debutants  qui  souvent  maitrisent  moins 
bien  la  finalite  du  systeme  n’utilisent  pas  les  automates 
avec  le  meme  sentiment  de  faire  corps  avec  la  machine, 
d’ou  une  moindre  efficacite  du  couple  homme-systeme. 

Get  ensemble  de  points  justifie,  si  besoin  en  etait,  le 
recours  a  de  la  simulation  afm  de  mieux  evaluer  Fimpact 
des  choix  d'aides  a  la  decision  sur  les  comportements  des 
operateurs. 

2.3  Systeme  communicant 

Par  essence,  Un  C3I  ne  fonctionne  pas  en  tant  que 
systeme  isole.  II  en  va  de  meme  pour  une  simulation  de 
C3I.  Les  informations  issues  d’autres  systemes  ou  capteurs 
peuvent  etre  simulees  ou  prises  dans  le  monde  reel.  De 
meme,  les  ordres  issus  de  Foperateur  (simule  ou  non)  du 


C3I  simule  doivent  recevoir  un  echo  exterieur  (compte- 
rendu,  changement  dans  les  flux  d’information  entrants. 

La  encore  les  entites  destinataires  peuvent  etre  simulees  ou 
reelles. 

Pour  communiquer  avec  des  systemes  reels,  on  utilisera 
les  liaisons  operationnels  et  pour  communiquer  avec  des 
systemes  simules  distants  on  utilisera  des  technologies 
existantes  ou  en  cours  de  standardisation  (ALSP,  DIS).  Si 
le  modele  de  C3I  fait  lui-meme  partie  d’une  simulation 
constructive,  les  communications  seront  simulees, 

3.  Simulation,  aide  a  la  decision  et 
facteur  humain  :  une  demarche 

3. 1  Du  constructif  au  virtual,  du  virtue!  au  reel. 

La  demarche  que  nous  proposons  n’echappe  pas  a  une 
phase  initiale  d’analyse  du  besoin  mais  reduit  celle-ci  au 
strict  necessaire  a  Felaboration  d’un  premier  modele 
grossier. 

Ce  premier  modMe  est  integre  a  une  ou  des  simulations 
technico-operationnelles  et  etudie  jusqu’a  obtenir  une 
specification  plus  detaillee  et  mieux  validee. 

Get  objectif  atteint  apres  un  certain  nombre  d’iterations 
peu  couteuses,  on  passe  a  une  modelisation  plus  fine 
pouvant  operer  eventuellement  en  temps  reel.  Des 
operateurs  humains  ainsi  que  des  systemes  ou  composants 
reels  peuvent  commencer  a  intervenir.  Cette  etape  peu 
donner  lieu  a  des  retours  sur  la  specification,  mais  son 
produit  essentiel  est  la  conception  architecturale  du 
systeme. 

A  la  fin  de  cette  phase,  la  specification  est  totalement 
validee,  et  le  systeme  a  demi  congu. 

La  derniere  phase  est  une  transformation  progressive  du 
simulateur  en  systeme  reel.  C’est  a  ce  stade  que 
s’efifectuent  les  choix  technologiques  determinants  en 
matiere  de  couts,  done  le  plus  tard  possible. 


3.2  La  phase  amont,  le  tout  numerique 

La  premiere  version  du  modele  de  C3I,  destinee  a  etre 
integree  a  une  simulation  a  grande  echelle,  sera  une 
traduction  naive  de  F  analyse  fonctionnelle  prealable  : 
simulation  de  sous-systemes  fonctionnels  parfaits  dans  un 
premier  temps  (pour  valider  la  premiere  analyse;  a  ce 
stade,  le  modele  sera  surtout  un  noeud  de  communication), 
puis,  le  besoin  valide,  on  affinera  la  simulation  de  maniere 
a  representer  Farchitecture  du  fiitur  C3I. 

S’agissant  de  modeliser  un  systeme  a  operateurs 
humains,  Finconvenient  ici  est  de  ne  pouvoir  integrer  un 
operateur  humain  (fonctionnement  non  temps-reel,  haute 
repetabilite),  II  sera  done  moddise  de  maniere  appropriee, 
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et  ce  qui  peut  se  faire  de  mieux  n’est  que  le  moins  mal 
possible. 

En  fait,  on  se  trouve  confronte  a  la  definition  d’un 
modele  de  comportement  d’operateur  qui  restera  invariant 
et  dont  les  reactions  face  a  des  taches  nouvelles  sont 
deduites  de  situations  approchantes.  Les  risques  de  biais 


La  caracteristique  majeure  d’une  simulation  a  evolution 
progressive  devant  aboutir  en  un  produit  final  operationnel 
est  la  qualite  de  son  architecture  de  base.  Elle  suppose  des 
le  depart  la  presence  d’une  epine  dorsale  a  la  fois  logicielle 
et  methodologique. 

Le  squelette  methodologique  sera  la  demarche  de 


numerique  constructif 

ALSP _ ^  ^ _ PIS 


finesse  croissante  des  mo  deles 


sont  dans  ce  cas  tres  importants  et  on  doit  considerer  le 
modele  resultant  comme  un  outil  de  predefinition  servant 
au  dimensionnement  du  systeme. 

3.3  Uapproche  du  reel,  rhomme  dans  la  boucle 

La  definition  des  IHM,  rendue  necessaire  par  la  presence 
de  rhomme  dans  la  boucle,  suppose  une  analyse  prealable 
des  besoins  operationnels  et  des  moyens  disponibles. 

La  recherche  des  informations  a  presenter  selon  le 
contexte,  la  structure  des  ecrans  ainsi  que  les  modalites  de 
dialogue  vont  resulter  de  la  definition  des  taches  preserves. 
11  convient  egalement  d’inferer  un  comportement  theorique 
de  I’operateur  face  aux  taches  a  accomplir  et  de  prendre  en 
compte  les  besoins  d’ anticipation  ainsi  que  les  contraintes 
temporelles  de  chaque  tache. 

Le  maquettage  des  solutions  IHM  constitue  une  etape 
indispensable  pour  en  permettre  la  validation  par  des 
operateurs  en  ternies  de  comprehension  des  modalites 
d’affichage  et  d’ organisation  des  ecrans. 

3.4  Les  outils  :  Papproche  objet,  revaluation 
ergonomique 


conception  et  de  developpement  objet,  Tepine  dorsale 
logicielle  sera  une  norme  de  communication  entre  objets 
eventuellement  repartis  (CORBA  nous  semble  un  exemple 
tres  prometteur  a  cet  egard). 

II  conviendra  d’eviter  le  foisonnement  d’objets  «  a  plat » 
lors  de  revolution  du  C3I  simule  :  les  objets 
«  fonctionnels  »  apparus  a  la  naissance  du  systeme  devront 
servir  chacun  d’espace  de  developpement  a  des  objets 
enfants  engendres  par  le  besoin  grandissant  de  detail.  Cette 
fagon  de  faire  presente  une  ressemblance  trompeuse  avec  la 
methode  HOOD  (Hierarchical  Object  Oriented  Design)  a 
cause  de  son  caractere  incremental  et  dynamique. 


La  presence  de  I’operateur  humain  dans  la  boucle 
suppose  qu’on  puisse  en  evaluer  au  mieux  le 
comportement.  Ce  point  reste  souvent  peu,  voire  pas 
aborde  dans  les  resultats  des  simulations.  Les  comptes- 
rendus  portent  en  efifet  bien  souvent  uniquement  sur  une 
evaluation  de  I’ergonomie  «  de  surface  »,  correspondant  a 
la  taille  et  a  la  couleur  des  symboles  et  des  caracteres, 
completee  par  un  avis  global  sur  la  simulation. 

L’abord  de  la  comprehension  effective  du  fonctionnement 
du  systeme,  1’ identification  des  modes  operatoires  ainsi  que 
la  notion  de  confiance  dans  les  automates  ou  dans  les  outils 
d’aides  constituent  pourtant  des  elements  essentiels.  Ils 
peuvent  etre  examines  par  I’etude  du  comportement  effectif 
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de  Toperateur  face  a  des  scenarios  de  test,  constmits  pour 
evaluer  un  ou  plusieurs  points  cles  d’ergonomie  :  besoin 
d’anticipation,  delai  pour  une  prise  de  decision, ...  Ceci 
suppose  une  demarche  d’ evaluation  ergonomique  avec  les 
etapes  suivantes  :  identification  a  priori  des  points  cles  a 
eviuer,  definition  des  sequences  de  tests  a  integrer  dans 
un  scenario  de  simulation,  description  du  comportement 
theorique  attendu  en  termes  d’ actions  operateurs  et  de 
modalites  de  dialogue,  observation  des  actions  pendant  les 
simulations  avec  enregistrement  des  traces  informatiques, 
entretiens  «  a  chaud  »  semi-ouverts  pour  faire  verbaliser 
les  enchainements  d’ actions  et  decrire  les  difficultes 
rencontrees.  La  confrontations  des  comportements  attendu 
et  reel,  fanalyse  des  erreurs  ou  des  omissions  ainsi  que  la 
reconstruction  des  modes  operatoires  effectifs  vont 
permettre  de  qualifier  in  fine  I’efficacite  de  la  cooperation 
homme-systeme. 


4.  Conclusion 

Ces  quelques  lignes  se  veulent  des  elements  de  reflexion 
pour  la  definition  d’un  fiitur  atelier  de  production  -  ce 
terme  couvrant  tout  le  cycle  de  vie  -  de  C3I. 

Des  sous-produits  interessants  de  cette  ligne  de 
developpement  pourront  etre  des  entraineurs  tactiques. 

La  demarche  ebauchee  permettra  de  reduire 
considerablement  les  couts  de  developpement  tout  en 
assurant  une  conformite  maximale  au  besoin. 

Elle  permet  egalement  de  prendre  en  compte  les  aspects 
de  comportement  des  operateurs  confrontes  a  un  nouveau 
systeme,  d’evaluer  leurs  difficultes  de  comprehension  (aide 
a  la  preparation  des  formations),  leurs  delais  de  reponse 
pour  une  bonne  reaction  ainsi  que  leur  confiance  probable 
dans  les  automates. 
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CONSTITUTION  D’UN  REFERENTIEL 
TERRAIN  POUR  LES  ENGAGEMENTS 
EXTERIEURS 


JP.  CAIMTELOU 
SAGEM 

Le  Ponant  de  Paris 
27  rue  Leblanc 

75512  Paris  Cedex  15,  France 


INTRODUCTION 

Pour  repondre  au  besoin  des  operationnel  en 
matiere  de  donnees  geographiques,  SAGEM  a 
lance  une  etude  sur  la  constitution  d'un 
referentiel  terrain  en  engagements  exterieurs. 

En  effet,  pour  assurer  la  reussite  d'une  mission 
lors  d'engagements  exterieurs,  les 
operationnels  ont  besoin  de  disposer  de 
donnees  geographiques  vecteur  fiables, 
necessaires  pour  les  SIC  (Systemes 
Informatiques  de  Commandement) . 

POSITION  DU  PROBL^ME 

L’objectif  de  cette  etude  est  d’analyser  et  de 
definir  un  systems  de  preparation  de  donnees 
terrain  permettant  de  repondre  au  besoin 
operationnel  dans  un  contexts  temps  de  crise, 
et  pour  des  zones  d’etendue  limitee  hors 
Centre-Europe. 

Les  donnees  terrain  sont  destinees  a  alimenter 
les  SIC,  ce  qui  impose  d’adopter  un  format  de 
donnees  standard.  En  I’occurrence,  nous  nous 
sommes  appuyes  sur  DIGEST,  qui  est  la  norms 
officielle  OTAN  pour  I’echange  de  donnees 
geographiques, 

Le  type  de  donnees  retenu  est  le  vectoriel 
renseigne  ou  attribue,  ce  qui  permet  d’une  part 
de  les  visualiser,  et  d’autre  part  de  les  interroger. 
Par  exemple,  il  est  possible,  pour  une  piste 
aerienne,  de  savoir  quelle  est  sa  longueur,  sa 
largeur,  son  orientation  et  son  revetement. 

La  zone  traitee,  dans  la  premiere  phase  de 
I'etude,  est  d’etendue  limitee  (de  I’ordre  de  100 
km  par  100  km).  Le  niveau  de  detail  des 
donnees  est  de  I’ordre  de  ce  que  Ton  trouve  sur 
une  carte  au  1 :50.000. 

Le  contexte  ‘lemps  de  crise”  implique  un  temps 
de  reponse  court  et  une  approche  iterative 
(fourniture  de  lots  de  donnees  intermediaires 
sans  attendre  la  fin  de  la  preparation  des 
donnees). 

Les  regions  du  monde,  hors  Centre-Europe, 
susceptibles  d’un  engagement  des  forces 
armees,  sont  souvent  mal  cartographiees,  et  ne 
beneficient  pas  d’un  travail  de  fond  de 
production  d’une  base  de  donnees 
cartographiques, 


comme  c’est  le  cas  pour  le  territoire  national.  Les 
donnees  disponibles  sur  ces  zones  sont  tres 
depouillees,  et  il  est  necessaire  de  les  enrichir, 
sur  une  zone  limitee  en  superficie,  pendant  le 
bref  delai  de  la  montee  en  puissance. 

DEMARCHE  DE  L’ETUDE 

L’etude  s’est  deroulee  selon  les  phases 
suivantes  : 

-  rencontre  avec  les  operationnels  pour 
formaliser  le  besoin, 

-  analyse  des  donnees  sources,  d’une  part 
celles  disponibles  en  metropole  et  d’autre 
part  celles  accessibles  sur  place  :  cartes 
papier,  images  satellitaires,  donnees 
thematiques,  renseignements 
operationnels,  donnees  vectorielles, 

-  definition  du  modele  de  donnees  du 
referentiel  terrain  a  partir  de  I’analyse  de 
besoin,  du  modele  de  reference,  du  modele 
issu  des  cartes  papier,  du  modele  de  photo- 
interpretation  des  images, 

-  synthese  des  methodes  a  mettre  en  oeuvre 
pour  constituer  le  referentiel  terrain  a  partir 
des  donnees  sources, 

-  synthese  du  besoin  realisable. 

L’etude  s’est  appuyee  sur  un  cas  concret  et  a 
pris  en  compte  des  donnees  reelles  en  quantite 
et  en  qualite. 

ANALYSE  DU  BESOIN 

Le  besoin  a  ete  indique  par  des  operationnels 
au  cours  de  plusieurs  reunions  de  recueil  du 
besoin. 

II  est  apparu  primordial  d’avoir  rapidement  des 
donnees  sur  la  zone,  meme  si  elles  sont 
incompletes  ou  geographiquement  imparfaites. 
De  meme,  les  donnees  thematiques  sont 
souvent  tres  importantes  (par  exemple,  la 
repartition  geographique  des  groupes 
ethniques).  . 

Le  besoin  des  operationnels  a  ete  exprime  sous 
forme  d’une  classification  en  themes,  sous- 
themes,  objets,  avec  pour  cheque  objet  un 
ensemble  de  caracteristiques  liees  a  I’emploi. 


Paper  presented  at  the  AGARD  MSP  3rd  Symposium  on  “Tactical  Aerospace  CT  in  Coming  Years'’, 
held  in  Lisbon,  Portugal  from  15th  May  to  18th  May  1995,  and  published  in  CP-557. 
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Les  themes  sent : 

-  donnees  geographiques  (hypsographie, 
geologie,  hydrographie,  couverture 
vegetale,  climatologie), 

-  voies  de  communication  (voies  routieres, 
voies  ferrees,  voies  maritimes,  voies 
navigables  et  voies  aeriennes), 

-  infrastructures  (zones  construites, 
equipements  de  communications,  principaux 
batiments  comme  les  hotels,  les  hopitaux, 
les  ecoles,  les  casernes,  les  representations 
diplomatiques,  ...), 

-  economic  (lignes  electriques,  sites 
industriels,  depots  de  carburant, ...), 

-  demographic  (repartitions  geographiques 
des  groupes  ethniques  et  des  courants 
religieux,  populations  etrangeres,  langues, 
...). 

On  trouve  done  deux  types  de  donnees  ;  des 

donnees  a  caractere  geographique,  et  des 

donnees  a  caractere  thematique. 


DONNIES  SOURCES 

Les  “donnees  sources”  sont  les  elements  qui 
vont  servir  de  matiere  premiere  pour  constituer 
le  referentiel  terrain. 

L’analyse  des  donnees  sources  a  permis 
d’identifier  les  sources  suivantes  : 

-  les  cartes  generates  de  type  IGN,  a  petites, 
moyennes,  et  grandes  echelles.  Les  cartes  a 
petites  echelles  ne  sont  pas  assez  detaillees 
pour  etre  interessantes.  Les  cartes  a 
moyennes  echelles  sont  en  general 
relativement  recentes,  et  peuvent  servir  de 
base  de  depart  a  la  constitution  du  referentiel 
terrain.  Les  cartes  a  grandes  echelles 
seraient  ideates,  mais  elles  sont  souvent 
anciennes  (cartes  de  plus  de  40  ans  par 
example),  ou  incompletes  (avec  des  zones 
blanches  non  cartographiees),  ou  meme 
inexistantes, 

-  les  cartes  thematiques  a  petites  echelles  et 

les  donnees  encyclopediques,  dont  on  peut 
disposer  sous  forme  papier  ou  sous  forme 
numeriques  sur  CDROM.  On  trouve  des 
cartes  de  relief,  de  type  de  sol, 
climatologiques,  hydrographiques, 
demographiques . 

-  la  cartographic  vectorielle,  encore  peu 
developpee,  comprenant  le  DCW  disponible 
sur  le  monde  entier,  mais  pas  tres  interessant 
du  fait  de  son  echelle  au  1/1.000.000,  et  le 
DEAD,  plus  interessant  du  fait  de  son  echelle 
au  1/250.000  ou  1/50.000,  mais  qui  n’est  en 
general  pas  disponible  dans  les  zones  a 
trailer. 


-  les  cartes  a  surcharge  aeronautiques  de  la 
DMA  (1/5.000.000  a  1/250.000), 

-  les  images  de  teledetection  (SPOT, 
LANDSAT), 

-  les  images  radar  (ERS1), 

-  les  photographies  aeriennes,  qui  peuvent 
aider  a  I'interpretation  des  images  satellites 
en  levee  de  doute, 

-  les  documents  touristiques,  e’est-a-dire  des 
cartes  touristiques,  en  general  recentes,  des 
guides  de  voyage,  des  plans  de  ville, 

-  les  donnees  operationnelles,  images  de 

reconnaissance  aerienne  ou  de  drone, 
dossier  d’objectif . 


MODELE  DE  DONNIES 

Le  modele  de  donnees  a  ete  elabore  a  partir : 

-  de  I’analyse  du  besoin  des  operationnels, 

-  des  modeles  de  donnees  sources  (legende 
dans  le  cas  des  cartes  papier,  modele  de 
photo-interpretation  pour  les  images 
satellitaires  et  les  photographies  aeriennes, 
...), 

-  du  modele  de  reference  (DIGEST  v1 .2). 

Le  squelette  du  modele  de  donnees  (themes  et 
sous-themes)  est  indique  dans  la  figure  qui 
suit  : 
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Cheque  sous-theme  est  constitu§  d’une 
collection  d’objets  (par  exemple,  route) 
auxquels  sont  affectes  des  attributs  (par 
exemple,  largeur,  composition  de  la  surface, 
periode  d'utilisation,  pratiquabilite, ...). 

Les  attributs  retenus  sont : 

-  soH  des  attributs  retenus  par  DIGEST  pour 
I’objet  considere  (par  exemple,  composition 
de  la  surface), 

-  soit  des  attributs  utilises  dans  DIGEST,  mais 
pour  d’autres  objets  (par  exemple,  periode 
d’utilisation), 

-  soit  des  attributs  n’existant  pas  dans  DIGEST 
(par  exemple,  pratiquabilite). 

Le  modele  de  donnees  a  ete  mis  en  forme  sous 
forme  de  fiches,  une  fiche  par  objet,  les  fiches 
etant  remplies  sur  papier  ou  sur  ecran  pendant 
la  phase  d’elaboration. 

On  s’est  attache  a  ne  prendre  en  compte  que  le 
besoin  realisable,  c’est-a-dire  a  ne  pas  mettre 
dans  le  modele  de  donnees  des  objets  ou  des 
attributs  que  Ton  ne  saura  pas  renseigner. 

M^THODES  DE  PRODUCTION 

Les  methodes  de  production  vont  permettre  de 
passer  des  donnees  sources  a  un  lot  de 
donnees  destinees  a  etre  chargees  dans  un 
SIC.  Les  methodes  vont  etre  mises  en  oeuvre 
sur  un  equipement  informatique  de  type  station 
de  travail,  en  utilisant  des  outils  du  commerce. 

Les  differentes  phases  sont ; 

-  I’acquisition  qui  peut  se  faire  par  pilotage 
d’un  scanner  pour  les  documents  papier,  ou 
par  support  des  formats  standards  pour  les 
donnees  sous  forme  numeriques  (par 
exemple,  les  formats  DIGEST  USRP  pour 
des  donnees  Raster,  DCW  pour  les  donnees 
vecteurs,  le  format  SPOT  Image), 

-  les  pre-traitements  geometriques  qui 
consistent  a  reperer  geographiquement  les 
donnees,  puis  a  les  projeter  dans  un 
referential  unique,  de  fagon  a  rendre  les 
diverses  donnees  sources  coherentes  et 
superposables  d’un  point  de  vue 
geographique, 

-  les  pre-traitements  radiometriques  qui 
permettent  d’ameliorer  la  qualite  d’affichage 
des  donnees  sources,  pour  faciliter  les 
phases  d’elaboration, 

-  la  vectorisation  qui  peut  se  faire  sur  papier  ou 
sur  ecran. 


Dans  la  methode  papier,  les  vecteurs  sont 
traces  sur  caique  par  un  operateur,  le  caique 
etant  deplace  sur  les  differents  documents 
sources  disponibles,  I’attribution  des 
vecteurs  se  faisant  sur  des  fiches  papier. 

Dans  un  deuxieme  temps,  le  caique  est 
vectorise  a  I’aide  d’un  outil  de  vectorisation 
automatique,  et  le  contenu  des  fiches  papier 
est  saisi. 

Dans  la  methode  sur  ecran,  I’operateur 
genere  les  vecteurs  a  partir  d’un  fond  de 
carte  numerise  en  utilisant  un  outil  de 
vectorisation  semi-automatique,  et 
renseigne  simultanement  les  vecteurs.  Cette 
deuxieme  methode  est  plus  rapide  que  la 
precedente,  mais  necessite  un  operateur 
plus  qualifie, 

-  le  renseignement  qui  va  permettre  d’attribuer 
les  vecteurs,  pendant  ou  apres  la 
vectorisation, 

-  la  mise  a  disposition  qui  consists  a 
selectionner  dans  la  base  de  donnees 
vecteur  un  ou  plusieurs  themes  pour  une 
zone  geographique  donnee,  et  a  les 
exporter  en  format  d’echanges  DIGEST, 
pour  alimenter  le  SIC. 

BESOIN  REALISABLE 

On  peut  distinguer  trois  phases  d’utilisation  de 
cette  etude  :  le  systems  “metropole”,  le 
systems  “projete”  et  le  systems  "projete  3D". 

Systems  “metropole” 

Le  systems  “metropole”  est  utilise  avant  que  les 
operationnels  ne  soient  presents  sur  le  terrain.  II 
est  constitue  par  des  personnels  specialistes,  et 
peut  mettre  en  oeuvre  des  moyens  “lourds” 
(scanner  grand  format,  traceur,  restituteur,  ...), 
soit  directement,  soit  en  faisant  appel  aux 
ateliers  de  production  de  donnees 
geographiques. 

Les  donnees  sources  exploitees  sont  celles 
disponibles  en  metropole  : 

-  des  cartes  papier  moyennes  echelles, 

-  des  cartes  papier  grandes  echelles,  si  elles 
existent, 

-  des  images  satellitaires,  une  fois 
approvisionnees, 

-  des  donnees  encyclopediques. 
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La  zone  qui  a  servi  de  support  a  I’etude  est 
situee  sur  le  continent  africain.  Sur  cette  zone 
de  100  km  sur  100  km,  une  couverture 
cartographique  complete  au  1 :50.000  etait 
immediatement  disponible,  mais  les  cartes 
etaient  pour  la  plupart  anciennes  (environ 
40  ans). 

Une  couverture  partielle  en  images  satellitaires 
(SPOT  et  LANDSAT)  a  ete  approvisionnee, 
mais  ces  donnees  n’ont  ete  disponibles  que 
bien  apres  les  cartes  papier,  la  procedure  etant 
plus  complexe  (choix  des  scenes,  commands, 
acheminement  des  donnees).  Une  situation 
reelle  de  crise  permettrait  de  reduire  ce  delai. 

La  realisation  du  referential  terrain  a  debute  a 
partir  des  cartes  papier,  qui  ont  permis  d’extraire 
les  reseaux  (routes,  pistes,  voies  ferrees, 
rivieres,  trait  de  cote),  I’hydrographie  et  I’emprise 
des  villages. 

Les  images  satellitaires  ont  ensuite  permis  de 
corriger  (plantation  disparue,  village  dont 
I’emprise  a  varie,  ...)  et  de  completer  (nouveaux 
reseaux,  lignes  electriques  par  example, 
nouvelle  plantation, ...)  le  referentiel  terrain. 


Systems  “projete” 

Le  systems  “projete”  est  utilise  sur  le  terrain. 
Les  personnels  qui  le  mettent  en  oeuvre,  s’ils 
ont  re9u  une  formation  (cartographie,  photo¬ 
interpretation,  ...),  ne  sont  pas  necessairement 
des  specialistes  geographes.  Les  moyens  a  leur 
disposition  sont  limites  (scanner  petit  format, 
imprimante,  station  de  traitement,  ...). 

Les  donnees  sources  sont  celles  disponibles 
sur  place  (cartes  papier  realisees  par  les  instituts 
geographiques  locaux,  plans  de  reseaux, 
donnees  recueillies  sur  le  terrain,  images  de 
reconnaissance, ...). 

Pour  la  zone  qui  a  servi  de  support  a  I’etude, 
des  donnees  sources  complementaires  ont  pu 
etre  approvisionnees  sur  place  :  couverture 
cartographique  recente  mais  partielle  au 
1:25.000,  photographies  aeriennes,  plans, 
donnees  a  caractere  thematique  (livres  d’ecole 
par  example),  couples  de  photographies 
stereoscopiques  (pour  determiner  un  Modele 
Numerique  de  Terrain  dans  les  zones  urbaines). 

Les  donnees  issues  du  systems  "projete"  sont 
au  format  vecteur,  elles  constituent  du  2D''^2 
Chaque  objet  est  defini  par  des  attributs 
descriptifs  ainsi  que  par  sa  hauteur. 


Systems  “projete  3D” 

Le  systems  “projete  3D”  est  utilise  sur  le  terrain, 
il  vient  en  complement  du  systems  "projete".  A 
partir  des  donnees  recueillies  lors  de  la 
constitution  du  referentiel  terrain  "projete", 
(Modele  numerique  de  terrain,  donnees 
vecteur),  les  operationnels  vont  constituer  un 
referentiel  3D.  A  partir  de  ces  donnees,  les 
operationnels  peuvent  obtenir  une  vue  3D 
realists  des  villes  et  pour  faciliter  le  suivi  et  la 
preparation  des  missions. 


CONCLUSION 

L’approvisionnement  en  donnees  terrain  des 
SIC  est  un  besoin  primordial.  Pour  les 
engagements  exterieurs  hors  Centre-Europe, 
ce  type  de  donnees  n’existe  pas,  et  I’etude 
constitution  d'un  referentiel  terrain  pour  les 
engagements  exterieurs  est  une  reponse  a  la 
demands  des  operationnels. 
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SUMMARY 

The  weather  FORepast  Utility  Model  (FORUM)  is  being 
developed  to  analyze  the  benefit  of  forecast  data  to  the 
operational  commander  in  the  field.  To  be  relevant  to  a  given 
operation,  such  a  model  must  reflect  the  concept  of  operations 
(CONOPs)  of  the  mission  under  study.  Thus,  tlie  modeler  must 
understand  the  operation’s  decision  process,  and,  in  particular, 
how  weather  data  influences  that  process.  Toward  that  end,  the 
description  of  FORUM  is  iUustrat^  by  an  air  munitions  mission, 
wherein  both  the  go/no-go  decision  and  a  tactical  payload 
alternative  are  decided  on  the  basis  of  weather  parameter 
predictions.  Single  target  mission  effectiveness  is  cast  in  the 
form  of  sorties  used  and  days  needed  to  complete  the  mission 
which,  in  this  case,  is  ground  target  destruction.  For  multiple 
weapon/target  site  scenarios,  effectiveness  can  also  be  expressed 
as  targets  killed  within  a  fixed  period  of  time  or  resources 
needed  to  negate  a  fixed  number  of  targets.  For  multitarget 
scenarios,  the  force  multiplicative  effects  of  correct  forecast  data 
is  manifested  via  such  metrics. 

The  weather  par  ameter  data  being  used  to  characterize  forecast 
accuracy  is  the  product  of  some  very  detailed  analyses  and 
simulation  of  the  forecast  process  from  satellite  measurement 
through  weather  parameter  prediction.  The  Forecast  Systems 
Laboratory  (FSL)  of  the  U.S.  National  Oceanic  and  Atmospheric 
Administration  (NOAA)  is  providing  satellite  measurement 
simulation  and  weather  parameter  prediction  for  a  sample  case 
within  the  continental  United  States.  The  statistical 
characterization  of  this  data  provides  some  of  the  input  for  the 
FORUM  model. 

INTEODUCTSON 

The  effects  of  weather  on  military  missions  is  historic  and 
ongoing.  From  the  days  of  the  Spanish  Armada  through  the 
D-Day  landings  in  Europe  to  present  day  difficulties  in  flying 
NATO  missions  over  Serbian  territory,  weather  has  played  a 
decisive  role  in  military  mission  performance.  The  advent  of 
improved  all-weather  sensors  and  combat  equipment  mitigates, 
but  does  not  supersede,  the  need  for  accurate,  timely  weather 
forecast  data  to  aid  the  commander’s  planning  process. 

This  paper  describes  a  utility  model  that  quantifies  the 
effectiveness  of  weather  forecast  data  applied  to  military  mission 
planning.  The  models  described  include  effects  of  satellite  data 
measurement,  the  forecast  process  and  its  accuracy  and 
timeliness,  military  mission  CONcepts  of  OPeration  (CONOPs), 
military  weapon  systems  performance,  and  the  effects  of 
nominal  weather  conditions.  Mission  effectiveness  is  calculated 
in  metrics  of  interest  to  the  field  commander  in  that  they  relate  to 
resources  expended  including  time  and  assets.  Sensitivity  to 
those  Measures  of  Effectiveness  (MOEs)  by  the  weather 
conditions  and  forecast  accuracy  lead  to  rationale  for  setting 
requirements  on  forecast  process  and  the  data  that  supports  it. 


The  end-to-end  modeling  and  analysis  process  will  be  described 
in  sequence  order  of  processing.  This  starts  with  the  processing 
of  satellite  measurement  data  to  the  point  of  generating  forecasts 
of  specific  weather  pai'ameters  over  a  range  of  prediction  times 
up  to  12  hours  in  advance.  The  accuracy  of  these  parameter 
forecasts  is  characterized  by  statistical  comparison  with  truth 
values  obtained  by  calibrated  ground  and  air  station  sensors. 
The  forecast  and  truth  data  serve  as  input  to  the  processes  of 
predicting  cloud  cover,  visibility,  and  the  thermal  environment 
experienced  within  the  military  combat  zone.  Models  of  the 
specific  military  mission  take  into  account  planning  CONOPs, 
systems  performance  (e.g.,  sensors  and  weapons),  and  the 
influence  of  true  weather  conditions  and  forecast  accuracy. 

To  motivate  and  illustrate  the  models  and  analysis  procedures,  a 
specific  mission  i§  analyzed:  that  of  tactical  air  munitions  drops 
on  fixed  ground  targets.  Focusing  on  this  specific  mission 
allows  visibility  of  how  mission-specific  CONOPs  and  system 
performance  influences  mission  effectiveness.  Exclusive  of 
these  effects,  however,  the  upfront  data  processing  and  top-level 
utility  models  are  applicable  to  a  broad  range  of  military  (and 
civil)  missions  that  can  be  supported  by  weather  forecast  data. 

Parametric  results  about  a  baseline  set  of  conditions  show  the 
sensitivity  of  mission  MOEs  to  weather  forecast  accuracy, 
weather  conditions,  and  mission-specific  systems  performar.ce. 
These  sensitivities  suggest  procedures  for  establishing 
requirements  of  satellite  measurement  accuracies  and  the  total 
accuracy  of  the  forecast  process. 

THE  DATA  FLOW  PROCESS 

The  volume  of  data  per  unit  time  flowing  from  the  source  sensor 
measurements  aboard  the  Air  Force’s  Defense  Meteorological 
Satellite  Program  (DMSP)  satellite  is  very  sizable.  This  satellite 
provides  optical  and  microwave  measurements  of  the 
atmosphere  in  both  temporal  and  spatial  extent  as  it  passes  over 
the  earth’s  surface  in  low  earth  orbit.  The  purpose  of  the  utility 
study  is  to  model  and  simulate  (end-to-end)  the  weather 
measurement  to  mission  effectiveness  process.  Figure  1  shows 
notionally  the  principal  analysis  functions  along  this  path.  As 
the  satellite  data  passes  from  left  to  right,  the  processing  steps 
distill  the  information  content  and  reduce  the  data  rate  from  the 
megabytes  per  second  collected  by  the  sensors  to  the  several 
scalar  MOEs  that  quantify  mission  performance  over  the  mission 
timeline. 

It  is  beyond  the  scope  of  this  paper  to  describe  in  detail  each  of 
the  upfront  weather  data  processing  algorithms.  Rather,  the 
primary  functions  of  these  processes  and  their  input/output 
interfaces  will  be  described  with  reference  to  descriptive 
documentation  where  appropriate.  The  Aerospace  Corporation 
(Aerospace),  which  provides  General  Systems  Engineering  and 
Integration  (GSE&I)  services  to  the  U.S.  Air  Force’s  Space  and 
Missile  Systems  Center,  and  the  National  Oceanic  and 
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Atmospheric  Administration’s  (NOAA)  Forecast  Systems 
Laboratory  (FSL)  have  cooperated  in  the  analysis  flow,  as  shown 
in  Figure  1. 

The  FSL  has  simulated  DMSP  weather  satellite  data  and 
processed  it  with  calibrated  ground  and  airborne  sensor  data  to 
provide  weather  parameter  forecasts  and  parameter  truth  values 
for  a  24-hour  span  of  time  representing  the  meteorological 
events  of  September  15,  1993  over  the  central  portion  of  the 
United  States  (Ref.  1).  A  rectilinear  data  grid  of  140-by-140 
cells  at  21  altitudes  is  projected  onto  a  polar  stereographic  map 
over  this  region  as  shown  in  Figure  2.  The  horizontal  cells  were 
about  12.1  km  per  side  and  the  vertical  cell  height  was  1  km. 

The  truth  or  control  weather  conditions  were  first  established 
over  this  grid  at  15-minute  intervals  starting  at  midnight 
Greenwich  Mean  Time  (GMT)^  on  September  15.  This  control 
grid  in  space  and  time  was  created  by  running  the  Regional 
Atmospheric  Modeling  Simulation  (RAMS)  (Refs.  2  and  3) 
simulation  with  local  and  boundary  condition  inputs  supplied  by 
hourly  ground  and  occasional  airborne  sensor  measurements  of 
weather  parameters  over  the  24-hour  period.  The  RAMS 
program  propagated  these  conditions  to  all  interior  grid  points 
over  that  time  span.  Figure  3  shows  a  typical  3-dimensional  plot 
of  truth  temperature  in  degrees  Kelvin  at  zero  altitude  over  the 
horizontal  grid. 

The  satellite-reconstructed  weather  parameters  over  the  spatial 
grid  are  created  by  an  FSL  simulation,  which  provides 
temperature  and  moisture  fields.  The  temperature  fields  are 
degraded  by  randomly  generated  variations  about  the  truth 
temperature.  Such  pseudo-satellite-generated  values  serve  to 
corrupt  the  control  values  at  the  12-hour  mark  past  midnight, 
which  is  the  starting  point  for  the  forecast  data  provided  in 
15-minute  increments  up  to  12  hours  after  this  reference  time  or 
24  hours  past  midnight  on  September  15.  Thus,  the  forecast  grid 
starts  with  the  truth  (control)  parameter  values  and  corrupts  them 
in  a  way  consistent  with  satellite-generated  weather  parameters 
at  the  12:00  noon  point  in  time.  The  forecast  grid,  past  noon, 
propagates  these  values  forward  every  15  minutes  to  the  next 
midnight  (i.e.,  the  forecast  runs  from  noon  on  the  15th  through 
midnight  on  the  16th  in  15-minute  increments).  The 
atmospheric  temperature  and  moisture  are  calculated  at  the  12- 
hour  point  to  simulate  the  satellite-reconstructed  values.  From 
these  parameters,  winds  and  cloud  height  fields  are  calculated 
geostrophically  and  hydrostatically.  The  1 2-hour  parameter  grid 
then  serves  to  initialize  a  forward  weather  propagation  in  time  in 
15-minute  increments  up  to  the  24-hour  grid  cutoff  point. 

At  the  end  of  this  processing  by  FSL,  two  temporal/spatial 
weather  grids  exist: 

the  truth  (control)  grid,  which  runs  24  hours  in 
15-minute  increments  midnight  GMT  on 
September  15  to  the  following  midnight 

•  the  forecast  grid,  which  is  the  same  as  the  truth 
grid  for  the  first  12  hours,  and  then  provides 
satellite-generated  parameter  forecasts  from  the 
12-hour  point  to  the  following  midnight 

Both  the  truth  and  forecast  databases  are  used  by  the  military 
utility  models  developed  and  used  by  Aerospace.  These 


databases  contain  140-by-140-by-21  spatial  gridpoints  at 
15 -minute  increments  over  a  24-hour  period.  They  represent 
many  megabytes  of  data.  The  weather  parameters  reported  at 
each  grid  point  include: 

•  temperature  (dry  bulb  and  dew  point) 

•  pressure 

•  wind  (direction  and  speed) 

•  cloud  mixing  ratio  (CMR) 

•  visibility 

•  total  precipitation 

Figure  1  now  shows  both  truth  and  forecast  weather  parameter 
databases  as  delivered  to  Aerospace  by  FSL.  At  this  point,  the 
parameter  values  for  both  truth  and  forecast  are  passed  forward 
to  three  separate  analysis  efforts  labeled  Military  Utility  Model 
Interface  in  Figure  1.  These  tasks  provide: 

•  statistical  characterization  of  the  difference  error 
between  the  truth  and  forecast  databases 

•  construction  of  cloud  regions  and  computation  of 
line  of  sight  viewing  and  cloud  extent  statistics 

•  initialization  of  a  precision-guided  munitions 
simulation  called  Electro-optical  Tactical 
Decision  Aid  (EOTDA)  (Ref.  4) 

Descriptions  of  the  latter  two  tasks  will  be  deferred  to  the 
sections  on  Military  Utility  Modeling,  because  they  depend  on 
the  particular  military  mission,  which  is  the  subject  of  this  paper. 

The  first  task  is  to  characterize  the  forecast  parameter  error  by 
calculating  sample  statistics  of  the  mean  and  standard  deviation. 
Figure  4  shows  a  sample  mean  and  standard  deviation  plot  for 
temperature  error  versus  forecast  time  over  a  6-hour  span  from 
the  forecast  starting  point.  The  solid  curve  represents  sample 
error  mean,  and  the  dotted  curves  represent  mean  ±  1  standard 
deviation  taken  over  a  lOO-by-100  inner  grid  of  horizontal 
position  cells  at  a  fixed  altitude.  The  sample  is  limited  to  this 
inner  subgrid  because  the  forecast  propagation  process  is,  in 
time,  corrupted  by  ground  truth  boundary  conditions  at  the  edges 
of  the  140-by-140  supergrid  over  which  the  forecast  is 
propagated.  These  same  sample  statistics  on  error  are  calculated 
for  each  weather  parameter  in  the  FSL  database  in  order  to 
characterize  weather  forecast  accuracy  for  future  military  utility 
analyses, 

AN  AIR  MUNITIONS  DROP  MISSION 

Before  proceeding  with  the  discussion  of  utility  modeling  and 
data  flow,  it  is  useful  to  describe  a  particular  military  mission. 
What  follows  will  involve  specific  features  of  that  mission  and 
how  weather  data  influences  the  decision  process.  The  mission 
under  consideration  is  that  of  tactical  ground  target  bombing  via 
aircraft  munitions  drops.  The  objective  is  to  kill  or  negate 
enemy  ground  targets  via  air  munitions  drops.  The  basic  choices 
for  the  flight  commander  are: 

•  whether  to  schedule  an  aircraft  sortie  for  a 
particular  target  on  a  given  day 


^  This  corresponds  to  6:00  p.m.  Central  Standard  Time  in  the  United 
States  on  September  14, 1993. 
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Figure  1 .  Military  utility  data  flow  overview. 


Figure  2.  Data  grid  projected  over  the  central  United  States. 
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Figure  3.  Temperature  distribution  over  a  horizontal  grid 
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Figure  4.  Weather  parameter  forecast  accuracy. 
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•  if  scheduled,  the  type  of  munition  to  use: 
gravity  bombs 


sorties  (days)  required  to  negate  a  fixed  number 
of  targets 


precision-guided  munitions  (PGMs) 

Figure  5  depicts  the  scenario.  The  advantage  of  correct 
sortie/target  site  pairing  is  to  be  found  in  fewer  aborted  or 
ineffectual  attack  sorties  that  may  result  from  unfavorable 
weather  conditions  over  the  target  site.  The  mission  elements 
consist  of  the  forward  command  and  control  center  making  the 
assignment,  attack  aircraft,  bomb  load,  and  target  site. 

During  a  normal  24-hour  attack  cycle,  mission  planning  will  be 
completed  at  6:00  a.m.  local  time  for  an  attack  plan  executed 
that  day,  and  the  process  will  be  repeated  on  a  daily  basis  during 
the  campaign.  The  daily  decision  and  attack  process  (Ref.  5)  is 
summarized  by  the  flow  shown  in  Figure  6.  At  the  start  of 
mission  planning  (upper  left  corner),  a  go/no-go  decision  is 
made  based  on  whether  the  cloud  ceiling  height  (CH)  exceeds 
10,000  ft^  over  the  target  site.  If  so,  a  go-ahead  is  given  for  the 
mission.  If  not,  the  target  is  recycled  to  the  next  day’s  plan.  The 
next  decision  after  go-ahead  is  the  selection  of  a  bomb  load 
between  gravity  bomb  and  PGM  alternatives.  PGM  is  chosen  if 
predicted  cloud  cover  (CC)  over  the  region  is  less  than  3/8  of  the 
sky. 

Once  the  sortie  is  launched,  there  are  five  possible  paths  of 
action  over  the  target  site: 

•  CH  is  below  10,000  ft,  in  which  case  the  mission 
is  aborted  (this  simplified  model  does  not  account 
for  secondary  or  tertiary  target  options) 

•  CH  is  above  10,000  ft,  PGMs  are  loaded,  and 
actual  CC  below  ceiling  is  less  than  3/8  (i.e., 
correct  bomb  choice) 

•  CH  is  above  10,000  ft,  gravity  bombs  are  loaded, 
and  actual  CC  below  ceiling  is  greater  than  3/8 
(i.e.,  correct  bomb  choice) 


The  model  descriptions  to  follow  use  the  weather  forecast 
information,  stated  concept  of  operations,  and  weapon  system 
performance  to  evaluate  the  above  stated  MOEs  for  both  single 
target  and  multitarget  scenarios. 

MILITARY  UTILITY  MODELING 

Now  consider  a  probabilistic  model  of  the  air  munitions  drop 
mission  for  a  single  attack  aircraft/target  pairing.  This  model 
provides  the  expected  number  of  days  to  target  kill  and  the 
sorties  flown  via  a  closed  form  algebraic  relation.  The 
simplicity  of  the  model  provides  insight  to  the  dependency  of 
mission  effectiveness  on  weather  forecast  accuracy,  nominal 
weather  conditions,  and  the  mission  CONOPs  and  weapon 
systems  performance.  A  more  general  Monte  Carlo  analysis  of 
multiple  attack/target  pairings  can  then  be  developed  from  the 
probability  functions  of  the  single  attack/target  model,  and 
restrictive  analytical  assumptions  can  be  relaxed  in  the  process. 

This  model,  which  will  be  called  the  FORecast  Utility  Model 
(FORUM),  uses  results  generated  by  other  weather  parameter 
and  weapon  performance  analyses  and  simulations  which  will  be 
described  below.  The  overarching  model  name  FORUM 
encompasses  a  number  of  separate  analyses  which  are  somewhat 
specific  to  the  air  drop  mission.  The  top-level  FORUM  model, 
however,  has  applicability  to  a  broad  range  of  military  and 
civilian  missions. 

THE  SINGLE  TARGET  MODEL 

The  FORUM  model  for  a  single  target  attack  scenario  seeks  to 
quantify  the  number  of  sorties  and  elapsed  days  until  a  target  can 
be  negated  under  the  assumption  that  one  sortie  (aircraft  flyout 
or  attack  effort)  can  be  mounted  per  day.  This  is  based  on  usual 
CONOPs,  wherein  attack  planning  proceeds  on  a  daily  cycle 
using  weather  and  intelligence/reconnaissance  information  on  a 
cyclic  basis  (Ref.  5). 


•  CH  is  above  10,000  ft,  PGMs  are  loaded,  and 
cover  below  ceiling  is  greater  than  3/8  (i.e., 
wrong  bomb  choice) 

•  CH  is  above  120,000  ft,  gravity  bombs  are 
loaded,  and  cover  below  ceiling  is  less  than  3/8 
(i.e.,  wrong  bomb  choice) 

Any  of  the  four  paths  resulting  in  attack  can  result  in  target 
negation  or  survival.  The  probabilities  of  their  result  vary  with 
the  load  type  and  the  actual  weather  conditions  over  the  target 
site. 

Since  early  negation  of  a  given  target  site  and  the  resources  used 
are  of  importance  to  the  field  commander,  the  MOEs  for  this 
mission  are: 


•  total  sorties  flown  per  kill 

•  number  of  days  elapsed  per  kill 

•  number  of  target  kills  among  a  fixed  set  within  a 
fixed  number  of  days 


The  probability  density  function  for  single  target  negation  is 
given  as  (Ref.  6): 


p(n,  k)  = 


(k-1)! 


(n-l)!  (k-n)! 


(Pl/'^  '^P3  (1) 


where 


p(n,  k) 

=  probability  target  is  negated  in  k  days 
by  n  sorties 

n 

=  number  of  sortie  attacks 

k 

=  number  of  days  to  negation 

Pi 

=  probability  of  no  sortie  being  flown 

P2 

=  probability  of  a  failed  sortie 

P3 

=  probability  of  a  successful  sortie  (i.e., 
target  negation) 

1 


This  conservative  CH  was  characteristic  of  operations  during  Desert 
Storm  to  protect  pilots  against  ground-to-air  attack. 


Note  that  Equation  1  assumes  day-to-day  independence  of 
events,  which  is  not  correct  for  weather-related  events.  For  now, 
this  assumption  will  be  allowed  to  stand  in  order  to  gain  insight 
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to  the  process.  The  Monte  Carlo  method  to  follow  does  not 
require  this  assumption,  and  day-to-day  correlations  can  be 
included  in  the  modeling  technique. 

WEATHER  FORECAST  USAGE  AND  EFFECT 

The  influence  of  weather  forecasting  on  this  process  is  via  the 
notion  of  good  and  bad  weather  from  a  go/no-go  planning 
perspective.  The  mission  planner  has  threshold  criteria  by  which 
he  judges  the  readiness  state  of  the  mission.  In  the  case  of 
weather,  these  criteria  are  based  on  weather  parameter  values 
forecast  for  the  target  area  at  the  planned  engagement  time. 
Thus,  the  above  probabilities  of  sortie  dispatch  and  success  or 
failure  are  linked  to  weather  and  planning  probabilities  as 
follows: 

Pi  =  prob  [no  sortie] 

=  Pf(Pg/b+Pb/b)*  Pbf 

P2  =  prob  [failed  sortie] 

=  “  Ps/g)(pg/g  *  Pgf  +  Pg/b  *  Pbf  *  (l  “  Pf ))  (3) 

“  Ps/b)(pb/g  *  Pgf  Pb/b  *  Pbf  *  (i  Pf)) 


Probabilities  of  good  or  bad  weather  at  the  target  site  given  good 
or  bad  forecasts  depend  on  the  weather  parameters  used  in  the 
mission  decision,  accuracy  of  forecasting  these  parameter 
values,  and  criterion  level  of  the  weather  parameters.  Figure  7 
shows  notionally  the  relationships  involved  for  a  typical  weather 
parameter.  Here,  the  chosen  parameter’s  distribution  function 
P(x)  has  a  criterion  level  C  such  that  P(C)  [the  probability  that 
(x  <  C)]  is  the  probability  of  good  weather.  The  distribution 
function  Pg  is  that  of  the  error  between  the  estimate  x  and  the 
actual  weather  value  x.  Thus,  the  probability  of  good  weather 
given  a  good  forecast  pg/g  is  the  normalized  density  weighted 

integral  over  all  good  weather  conditions  [cq  <  x  <  C],  of  the 
probability  of  having  a  good  forecast  (i.e.,  P^  (C  ~  x)). 

Let  us  now  assume  that  the  weather  density  P(x)  is  constant  over 
the  criterion  interval  [Co,C].  The  Tchebycheff  Inequality 
(Ref.  7)  can  be  applied  to  the  error  distribution  Pg  having 
standard  deviation  Og,  to  yield: 


P3  =  prob  [successful  sortie] 

=  Ps/g  (Pg/g  *  Pgf  +  Pg/b  *  Pbf  (1  -  Pf)) 

+  Ps/b  (Pb/g  *  Pgf  +  Pb/b  *  Pbf  (1  -  Pf  )) 

where 


(4) 


If  Pg  (C  -  x)  is  now  approximated  by  Equation  5  to  a  minimum 
value  of  1/2  (corresponding  to  such  a  large  Gg  that  the 
probability  of  a  good  forecast  is  even  with  a  bad  forecast),  then: 


(C-Co)  2(C-Co)^ 


pf  =  probability  forecast  information  is  used  in 
mission  planning  (pf  =  0  means  no  forecast 
used) 

Pg/jj  =  probability  target  site  has  good  weather 
given  a  bad  weather  forecast 

Pb/b  =  probability  target  site  has  bad  weather  given 
a  bad  weather  forecast 

Pg/g  =  probability  target  site  has  good  weather 
given  a  good  weather  forecast 

Pb/g  =  probability  target  site  has  bad  weather  given 
a  good  weather  forecast 

Ps/g  =  probability  of  successful  sortie  given  good 
weather  at  target  site 

Ps/b  =  probability  of  successful  sortie  given  bad 
weather  at  target  site 

Pgf  =  probability  of  good  weather  forecast 

Pbf  =  probability  of  bad  weather  forecast 


for  [O  <  Oe  <  (C  -  Co)] 

This  approximation  converges  to  pg/g  =  1  for  Gg  =  0  [no  forecast 
uncertainty]  and  to  pg/g  =  1/2  forG£=(C~Co)  [largest 
forecast  uncertainty].  Since  pg/g  and  p^/g  are  mutually  exclusive 
and  complementary  probabilities: 

Pb/g  =  1  ~  Pg/g  (^) 

A  similar  line  of  reasoning  using  the  bad  weather  region 
[C  <  X  <  Cl]  yields: 

1  ctp  Gp^ 

and 

Pg/b  =  1  -  Pb/b 

WEAPON  EFFECTIVENESS  AT  THE  TARGET  SITE 
Once  at  the  target  site,  the  mission  is  aborted  if  the  CH  is  below 
10,000  ft  (i.e.,  the  ceiling  forecast  was  wrong).  If  PGM  weapons 
are  on  board,  the  probability  of  cloud  free  line  of  sight  (CFLOS) 


(8) 


(9) 


In  the  context  of  the  air  munitions  drop  CONOPs,  good  and  bad 
weather  refers  to  the  CH  criterion. 


24-8 


is  used  to  determine  if  an  unobscured  target  is  visible.  If  not,  the 
mission  is  aborted.  The  lock-on  range,  determined  by  the 
EOTDA  simulation,  is  used  to  evaluate  the  CFLOS  probability. 

If  gravity  bombs  were  loaded,  the  CFLOS  probability 
determines  whether  or  not  they  will  be  dropped.  If  the  target  is 
not  killed  by  reason  of  weapon  failure  or  sortie  abort,  it  cycles  to 
the  next  day’s  mission  planning. 

Now  convert  these  CONOPs  of  Figure  6  to  a  model  format. 
Equations  3  and  4  used  the  mission  success  probabilities  given 
good  and  bad  weather  on  target,  ps/g  and  ps/b,  respectively. 
Here,  good  weather  refers  to  CH,  and  by  the  mission  CONOPs, 

=  0,  because  the  mission  is  aborted  if  the  actual  CH  is  below 
10,000  ft.  If  the  ceiling  on  target  is  good,  there  are  four 
independent  paths  to  success  depending  on  the  weapon  load  and 
the  CC  over  the  target  area: 

•  PGM  with  CC  <  3/8  (CC  forecast  correct) 

•  PGM  with  CC  >  3/8  (CC  forecast  incorrect) 

•  gravity  bomb  with  CC  <  3/8  (CC  forecast 
incorrect) 

•  gravity  bomb  with  CC  >  3/8  (CC  forecast  correct) 

These  paths  translate  to  the  following  value  for  probability  of 
success  given  good  ceiling  weather  ps/gi 

Ps/g  =  [l  “(l  “  Pkp)BOTp/gc]»  PCFLOSp/gc  •  Pgc/gcf  •  Pgcf 
+[l  -(l  -  Pkpj^^'^p/bc]*  PCFLOSp/bc  •  Pbc/gcf  *  Pgcf 
_l-|l  _  Pkgb)®^'^gb]^^^^^gb/gc  •  Pgc/bcf  *  Pbcf 

+1^1  —^1  —  Pkgbj^^'^gbjP^^^^gb/bc  *  Pbc/bcf  *  Pbcf 

(10) 

BOTp/gc  =  BLOADp  *  PLOgc  (11) 

BOTp/bc  =  BLOADp  *  PLObc  (12) 


PLOfjc  — 

probability  of  PGM  lock-on  in  bad 
CC  (derived  from  EOTDA 
simulation  and  scenario  standoff 
range) 

PCFLOSp/gc  = 

probability  of  CFLOS  for  PGM  in 
good  CC 

PCFLOSp/bQ  = 

probability  of  CFLOS  for  PGM  in 
bad  CC 

PCFLOSgb/gc  = 

probability  of  CFLOS  for  gravity 
bomb  in  good  CC 

PCFLOSg|3/j30  = 

probability  of  CFLOS  for  gravity 
bomb  in  bad  CC 

Pgc/gcf  = 

probability  of  good  CC  given  good 
forecast 

-;Ccc=3/8 


(13) 


^cc 


Pbc/gcf 


=  standard  deviation  of  CC  forecast 
error 

=  probability  of  bad  CC  given  good 
forecast 

”  1  ”  Pgc/gcf 


Pbc/bcf  =  probability  of  bad  CC  given  bad 

forecast 


2 

Q^cc  ^  ^cc 
(l-Ccc)  2(1-Cccf 


(15) 


Pgc/bcf 


=  probability  of  good  CC  given  bad 
forecast 

=  1  -  Pbc/bcf 


Pgcf 

Pbcf 


probability  of  good  CC  forecast 
probability  of  bad  CC  forecast 


where 


Pkp 


Pkgb 

BOTp/gc 

BOTp/bc 

BOTgb 

BLOADp 

PLOgc 


=  probability  of  kill  per  single  PGM 
weapon 

=  probability  of  kill  per  single 
gravity  bomb 

=  bombs  on  target  for  PGM  in  good 
CC 

=  bombs  on  target  for  PGM  in  bad 
CC 

=  bombs  on  target  for  gravity  bomb 
given  visibility  of  the  target 

=  pgm  bomb  load  per  sortie 

=  probability  of  PGM  lock-on  in 
good  CC  (derived  from  EOTDA 
simulation  and  scenario  standoff 
range) 


The  FORUM  described  above  can  be  summarized  by  Figure  8, 
wherein  the  weather  forecast  accuracy,  mission  CONOPs  usage 
of  weather  data,  weapon  effectiveness,  and  actual  weather 
conditions  all  affect  the  mission  MOEs:  sorties  expended  and 
days  elapsed  to  mission  success. 

MULTITARGET  EXTENSIONS  AND  FORCE 
MULTIPLICATION 

The  FORUM  described  above  is  for  a  single  target.  It  is 
desirable  to  look  at  multitarget/multisortie  scenarios,  because  a 
real  payoff  in  resource  saving  via  forecast  usage  is  the  force 
multiplication  effect  in  a  theater  campaign  environment.  Over  a 
large  theater  area  covered  by  many  potential  targets  of  varying 
value,  the  theater  commander  would  like  to  place  his  resources 
where  they  are  most  effective  in  a  target  value  sense. 

For  example,  if  some  high  value  targets  repeatedly  are  made 
inaccessible  to  attack  due  to  weather  conditions,  the  commander 
would  like  to  allocate  resources  on  those  days  to  lesser  value 
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Cq  5  C  Weather  parameter  x 

(Forecast) 


Pg/g  (C-x)P(x)dx]/[J  p(x)dx] 

^0  ^0 

Pg/g  =  probability  of  good  weather  given  a  good  weather  forecast 
p(x)  =  density  function  of  actual  weather  parameter  x 

Pe(*)  =  distribution  function  of  weather  parameter  x  measurement  forecast  error 
Figure  7.  Weather  parameter  accuracy  effect  on  forecasts. 
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conditions 
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Figure  8.  FORUM  single  target  model  flow. 
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0  Weapon  sites 
^  Target  sites 


■  ’  IVl 

V  =  engagement  value  =  [1-7i(pjj)'^ij] 

j  ^ 

pjj  =  probability  of  unsuccessful  attack  by 
weapon  site  i  on  target  site  j 
Vj  =  value  of  target  site  j 
mjj  =  number  of  weapon  i  sorties  on  target  j 
N  =  number  of  target  sites 
M  =  number  of  weapon  sites 


^Target  site  j 


^  Weapon  site  i 


Pjj  -  [1 

Pjj  =  probability  of  successful  weapon  I  attack  on  target  j 
a|j  =  accessibility  of  site  i  to  j 

?  mjj  <  Oj 

Oj  =  number  of  weapons  at  site  i 


Figure  9.  Day  k  of  campaign  theater  model. 
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Figure  10.  Weapon  visibility  and  delivery  analyses. 
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accessible  targets  so  that  each  day  the  commander  is  able  to 
allocate  resources  in  an  expected  high  rate  of  return  fashion. 
This  allows  him  to  cover  more  targets  with  the  same  resources, 
or  it  reduces  the  forces  needed  to  cover  a  fixed  set  of  targets. 

Let  us  formulate  this  problem  as  depicted  in  Figure  9.  The 
number  of  sorties  sent  by  the  commander  on  any  given  day  is  a 
function  of  target  value,  number  of  sorties  available, 
accessibility  of  weapon  sites  to  the  targets,  and  probability  of 
success  per  assignment.  This  last  parameter  is  influenced  not 
only  by  the  weapon  effectiveness  but  also  by  the  effects  of 
weather  and  weather  prediction  on  the  CONOPs  in  effect.  As 
we  saw  in  the  single  target  case  described  above,  this  probability 
can  be  related  to  these  effects  by  a  probabilistic  model  that 
incorporates  the  CONOPs  decision  criteria,  weather  forecast 
accuracy,  type  of  weather  expected,  and  weapon  ability  to  act  in 
good  and  bad  weather. 

By  simulating  this  problem  in  Monte  Carlo  fashion  for  a 
representative  command  assignment  algorithm,  one  can 
highlight  the  force  multiplication  advantages  of  weather  forecast 
usage.  Expected  mission  MOEs  would  be  targets  killed,  target 
value  killed,  resources  expended,  and  elapsed  days  to  mission 
completion.  Resources  expended,  in  particular,  will  highlight 
the  force  multiplicative  benefits  of  weather  forecasts  and 
sensitivity  to  forecast  accuracy.  Note  also,  that  the  Monte  Carlo 
formulation  does  not  require  the  assumption  of  day-to-day 
independence  of  event  probabilities,  since  any  correlation  can  be 
explicitly  modeled  in  the  pseudo-random  draw  processes. 

The  choice  of  weapon  sorties  on  targets  my  is  made  sequentially 
starting  with  the  most  valuable  surviving  target  on  any  given  day 
and  working  toward  the  least  valuable  survivor  until  all  sortie 
resources  are  expended.  The  probability  of  no  sortie  on  a  given 
target  due  to  bad  weather  is  drawn  from  probability  pj  of 
Equation  2,  and  this  target  is  removed  from  the  targeting  list  on 
that  day.  Then  Py  of  Figure  9  is  taken  to  be  the  same  as  p3  of 
Equation  4  for  each  weapon/target  pairing  (i,  j)  in  the  scenario 
when  the  weapon  assignments  are  made.  The  actual  target  kill 
probability  is  drawn  from  Equations  10-16  as  actual  weather 
conditions  are  drawn  per  target  site. 

CLOUDS  AND  WEAPON  VISIBILITY 

The  remaining  portions  of  the  analysis  effort  are  mission  specific 
in  that  they  deal  with  CFLOS  visibility  (Ref.  8)  and  PGM 
performance  at  the  target  site  (Ref.  9).  Figure  10  shows  an 
overview  of  the  principle  analysis  tasks  associated  with 
generating  the  probabilities  of  CFLOS  and  PGM  lock-on  in 
Equations  10-12.  The  analyses  that  generate  these  probabilities 
are  interconnected  as  shown  in  Figure  10.  Of  interest  are  the 
actual  weather  conditions  to  be  experienced  by  the  weapon 
system  over  the  target  area.  Thus,  the  FSL  truth  database  is 
accessed  for  these  analyses.  Of  particular  interest  are  subareas 
of  the  140-by-140  horizontal  grid  within  which  local  CC  is  good 
(i.e.,  cover  <  3/8)  and  bad  (i.e.,  cover  >  3/8).  To  select  these 
subareas,  cloud  surfaces  must  be  generated  from  FSL  CMR  data 
using  a  threshold  criterion  of  CMR  >  0.0001  to  define  cells 
within  which  opaque  clouds  exist  (Ref.  8). 

Figure  1 1  shows  a  sample  reconstruction  of  the  cloud  field  over 
the  study  region  at  six  hours  after  the  beginning  of  forecast 
creation  (i.e.,  18  hours  after  midnight  GMT).  The  analyst  selects 
local  regions  where  CC  (i.e.,  average  CFLOS  visibility)  is  above 
and  below  the  3/8  criterion  level.  These  are  designated  good  and 


bad  CC  regions,  and  their  location  and  extent  are  handed  to  the 
PGM  analysis  via  EOTDA  (Ref.  9). 

The  EOTDA  simulation  is  a  complex  code  that  determines 
electro-optical  sensor  lock-on  range  as  a  function  of  target 
signature,  background  signature,  weapon/target  viewing 
geometry,  and  weapon  sensor  design.  Target  and  background 
signatures  start  with  a  selection  of  types  among  a  comprehensive 
list  of  alternatives.  The  signatures  are  calculated  using  a  24-hour 
history  of  temperature,  humidity,  wind,  and  precipitation  data 
supplied  by  the  FSL  database.  Detailed  heat  flow  calculations 
determine  temperature  and  signature  levels  at  the  end  of  this 
time.  The  weapon  sensor  design  type  and  weapon/target 
viewing  geometry  then  determine  the  target/background  contrast 
level  and  the  ranges  at  which  the  target  can  first  be  detected  and 
then  resolved .  against  the  background.  The  resolution  range, 
which  is  generally  shorter,  is  used  as  the  lock-on  range  for  the 
particular  engagement  under  consideration.  The  user  is  faced 
with  many  complex  alternatives  in  simulating  a  scenario.  The 
approach  taken  here  is  to  make  those  selections  so  that  the 
conditions  are  representative  of  the  full  spectrum.  When 
considering  a  target  approach  heading,  it  is  assumed  that  the 
pilot  can  adapt  to  find  a  preferred  approach  angle  for  lock-on. 
The  EOTDA  then  provides  the  nominal  lock-on  range  for  the 
good  and  bad  weather  subareas.  The  EOTDA  is  also  used  over  a 
range  of  engagement  conditions  to  determine  probability  of 
lock-on.  The  lock-on  range  under  each  condition  is  passed  to  an 
analysis  of  CFLOS  visibility  as  shown  in  Figure  10. 

CFLOS  analysis  uses  a  ray  tracing  approach  to  determine  the 
probability  of  CFLOS  at  any  given  point  on  the  grid.  Figure  12 
shows  a  typical  ray-trace  locus  of  points  for  many  azimuths  and 
ground  ranges  emanating  from  a  single  viewing  point.  Rays  are 
traced  from  potential  aircraft  locations  to  all  ground  level  grid 
points  within  a  specified  range.  If  any  ray  starts  its  path  in  a 
cloud  or  intersects  a  cloud,  it  is  considered  to  be  a  non-visible 
ray.  All  visible  rays  divided  by  the  total  rays  yields  the 
probability  of  CFLOS  at  the  viewing  point.  Such  analyses  are 
conducted  in  the  good  and  bad  CC  subareas  for  weapon  ranges 
of  PGM  and  gravity  bomb  weapons  to  produce  the  probabilities 
of  Equation  1 0.  The  PGM  range  limit  comes  from  the  EOTDA 
analysis.  The  gravity  bomb  value  is  taken  from  Figure  13, 
which  shows  the  standoff  range  versus  drop  altitude  for  varying 
aircraft  speeds.  This  figure  was  generated  using  a  simple  free- 
fall  Newtonian  gravity  model  without  atmospheric  drag 
consideration.  The  nominal  aircraft  speed  is  500  km/hr  (~  330 
mph)  and  the  drop  altitude  is  3  km  (~  10,000  ft),  which  results  in 
a  standoff  range  of  3  km. 

Figure  14  summarizes  the  scenario  concept  and  analysis  steps 
that  model  it.  Both  truth  and  forecast  weather  parameter 
databases  are  generated  by  FSL  using  calibrated  ground 
measurements  and  a  simulation  of  satellite-generated 
measurements  to  initiate  the  forecast  path.  These  databases  are 
used  by  Aerospace  to: 

•  statistically  characterize  forecast  accuracy 

•  develop  CFLOS  probabilities 

•  initiate  thermal  analysis  of  PGM  weapon  electro- 
optical  sensors 
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Figure  1 1 .  Cloud  cover  over  the  central  United  States  (vertical  scale  exaggerated). 


Figure  12.  Aircraft-to-ground  visibility  via  ray  tracing  (vertical  scale  exaggerated). 
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Table  1.  FORUM  Input  Baseline 


Parameter 

Description 

Units 

Value 

^cht 

Critical  CH  for  mission  go/no- 
go 

km 

Var 

(oo) 

^cht 

CH  forecast  uncertainty 

km 

Var  (0) 

Ccc 

Critical  CC  for  weapon  load 
decision 

- 

3/8 

^cc 

CC  forecast  uncertainty 

- 

Var  (0) 

Pf 

Probability  forecast  is  used  by 
mission  command 

- 

1.0 

Pkp 

Probability  of  single  precision- 
guided  bomb  kill 

- 

0.4 

Pkgb 

Probability  of  single  gravity 
bomb  kill 

- 

0.08 

PLOgc 

Probability  of  PGM  lock-on 
given  good  CC  and  CFLOS 

- 

1 

PCFLOSp/gQ 

Probability  of  PGM  CFLOS 
given  good  CC 

- 

1 

PLObo 

Probability  of  PGM  lock-on 
given  bad  CC  and  CFLOS 

1 

PCFLOSp/bQ 

Probability  of  PGM  CFLOS 
given  bad  CC 

- 

0 

PCFLOSgb/gQ 

Probability  of  gravity  bomb 
CFLOS  given  good  CC 

- 

1 

PCFLOSgb/bc 

Probability  of  gravity  bomb 
CFLOS  given  bad  CC 

- 

4/8 

mxmcdays 

Maximum  Monte  Carlo  days 
per  scenario  engagement 

days 

20 

mctrgst 

Number  of  target  sites  per 
Monte  Carlo  engagement 

target 

sites 

10 

mcwpnst 

Number  of  weapon  sites  per 
Monte  Carlo  engagement 

weapon 

sites 

1 

mxsortie_ 

wpnst 

Maximum  sorties  per  weapon 
site  per  day 

sorties 

5 

BLOADp 

Maximum  PGM  bomb  load 
per  sortie 

bombs 

5 

BOTgb 

Maximum  gravity  bombs  per 
sortie 

bombs 

5 

ceilhtmn 

(ceilhtmx) 

Minimum  (maximum)  CH  for 
weather  distribution 

km 

0(10) 

covermn 

(covermx) 

Minimum  (maximum)  CC  for 
weather  distribution 

- 

0  (1) 

These  analyses  in  turn  feed  the  FORUM  input  process,  which 
evaluates  resources  used  and  time  required  to  complete  an  air¬ 
dropped  munitions  mission. 

PARAMETRIC  ANALYSIS  RESULTS  AND 
IMPLICATIONS 

As  a  means  of  gaining  insight  to  the  process  and  an 
understanding  of  its  significance,  a  baseline  case  and  sensitivity 
analysis  were  conducted  using  this  model.  In  what  follows, 
current  best  data  values  were  used  and,  in  some  cases,  the  results 
are  parameterized  over  a  range  of  possible  values  in  order  to 


demonstrate  sensitivity  of  the  MOEs  to  principle  performance 
parameters.  Table  1  shows  the  baseline  values  assumed  for  this 
study.  The  first  column  contains  the  parameter  symbol,  the 
second  a  brief  description,  units  in  the  third,  and  value  in  the 
fourth.  Where  a  Var  notation  appears,  this  parameter  takes  on 
varying  value  for  the  sensitivities  analyses  and  a  baseline  value 
as  shown  in  parentheses  (i.e.,  the  value  when  this  parameter  is 
not  varied). 

The  scenario  considered  is  that  of  ten  separate  target  sites  to  be 
accessed  by  a  single  weapon  site  with  up  to  five  sorties  per  day 
allowed.  The  dimensions  of  the  problem  in  terms  of  target  and 
weapon  sites  and  sortie  resources  could  be  expanded,  but  were 
kept  small  for  purposes  of  exploration.  The  go/no-go  CH 
threshold  was  varied  to  allow  varying  probability  of  being  above 
the  threshold  with  a  fixed  distribution  of  CH  values.  The 
forecast  uncertainty  on  CH  and  CC  were  also  allowed  to  vary  in 
order  to  view  MOE  sensitivity  to  these  forecast  accuracy 
parameters. 

The  first  study  varied  the  CH  threshold  or,  equivalently,  the 
probability  of  any  target  site  being  above  the  threshold  and  CH 
forecast  accuracy.  Of  particular  interest  is  the  number  of  sorties 
flown  per  target  kills  as  shown  by  Figure  15.  The  weapon 
delivery  and  kill  assumptions  that  allow  near-perfect  kill 
conditions  when  a  mission  is  launched  provide  for  just  above 
one  sortie  per  target  kill  when  the  CH  forecast  accuracy  is 
perfect  (i.e.,  Ocht  =  0)-  As  this  uncertainty  increases  up  to  a 
maximum  of  0cht  =  4  km,  increased  sorties  are  required  per  kill 
to  account  for  failed  missions  when  the  CH  is  less  than  expected 
at  the  target  site.  The  sorties  also  increase  with  decreasing 
probability  of  having  a  CH  above  the  threshold,  because  this 
type  of  mission  failure  occurs  more  frequently.  The  dotted  line 
represents  the  case  in  which  weather  CH  forecast  information  is 
not  used  by  the  mission  planner  (i.e.,  sorties  are  flown  as 
available  against  the  targets  without  knowledge  of  the  CH 
conditions  over  the  target  sites).  As  might  be  expected,  this 
policy  approaches  the  forecast  performance  as  the  probability  of 
good  CH  weather  increases.  When  CH  conditions  are  poor  (i.e., 
probability  of  good  CH  <  0.5)  the  policy  without  forecast  results 
in  more  than  twice  the  sorties  as  the  policy  using  perfect  CH 
forecast  information.  This  is  another  way  of  saying  that  weather 
forecasts  are  most  valuable  in  poor  weather  conditions  (i.e., 
tropical  versus  desert  environments). 

If  one  were  to  consider  setting  a  requirement  on  CH  forecast 
accuracy,  the  breakpoint  for  using  a  forecast  policy  and  no 
forecast  might  be  around  the  nominal  probability  of  good  CH  at 
0.75  or  less.  This  represents  a  level  of  ideal  conditions  found  in 
the  Desert  Storm  experience  (Ref.  5).  For  weather  conditions 
above  this  level,  forecast  policy  would  do  no  better  than  a  no¬ 
forecast  dispatch  policy  if  the  CH  forecast  accuracy  were 
Ocht  -  2  km.  This  would  be  a  required  level  of  CH  forecast 
accuracy  to  reap  the  benefits  of  forecast  assignment  in  scenarios 
involving  consistently  low  CH  conditions. 

Now  consider  the  effect  of  CC  forecast  accuracy  on  mission 
performance.  This  parameter  influences  the  decision  as  to 
whether  PGMs  or  gravity  bombs  are  to  be  loaded  per  sortie. 
Since  weapon  effectiveness  in  good  and  bad  CC  conditions  are 
wrapped  in  that  sensitivity,  the  number  of  sorties  flown  is  not  as 
strongly  influenced  by  forecast  accuracy  if  the  weapons  have 
similar  kill  effectiveness  (i.e.,  the  loading  decision  is  not  critical 
if  weapon  effectiveness  is  the  same  with  either  decision). 


Expected  sorties  flown  per  target,  unitless 


Total  PGM  usage 


10  target 
1  weapot 
5  sorties 


Probabllitv  of  aood  cloud  cover,  unitless 


Probability  of  sortie  success,  unitless 
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Figure  16  shows  the  effect  of  actual  CC  probability  and  forecast 
accuracy  on  the  number  of  sorties  flown  per  target.  Also  shown 
by  the  dotted  curve  are  the  sorties  flown  versus  CC  probability 
when  PGMs  are  used  exclusively  (i.e.,  every  sortie  is  flown  with 
PGMs). 

Figure  16  shows  that  the  loading  decision  decreases  sorties 
flown  over  the  PGM  loading  policy  for  probability  of  good  CC  < 
0.75  when  the  CC  forecast  uncertainty  is  Ccc  ^  1/16.  This 
suggests  that  a  requirement  on  CC  uncertainty  might  be  set  at  the 
1/16  (one  sigma)  level  to  assure  benefits  of  the  weapon  loading 
decision  in  less  than  fair  weather  conditions.  Another  metric  for 
viewing  the  influence  of  the  weapon  loading  decision  is  depicted 
in  Figure  17,  which  shows  the  probability  of  sortie  success  (i.e., 
target  kill)  versus  the  probability  of  good  CC  and  CC  forecast 
uncertainty.  Here  again,  the  policy  of  loading  PGMs  exclusively 
crosses  the  forecast-guided  loading  curves  when  the  probability 
of  good  CC  is  0.75  and  CC  forecast  uncertainty  is  1/16.  These 
numbers  are  not  important  now  since  they  are  the  result  of 
preliminary  analyses  on  limited  case  data.  However,  the 
procedures  suggested  for  setting  a  requirement  may  be  worthy  of 
further  expansion. 

Another  interesting  MOE  that  reflects  the  force  multiplicative 
advantage  of  forecast  scheduling  is  shown  in  Figure  18.  Here 
the  number  of  target  kills  accomplished  within  a  fixed  number  of 
days  is  plotted  against  the  probability  of  good  CH  conditions. 
Pairs  of  curves  are  shown  for  maximum  day  limits  of  one,  three, 
and  ten  days.  Each  pair  of  curves  contains  one  using  perfect 
forecast  information  (i.e.,  acht  =  0)  and  are  without  using 
weather  forecast  CH  (i.e.,  sorties  are  scheduled  against  targets 
without  consideration  of  mission  abortion  due  to  the  target  site 
CH).  When  the  maximum  time  is  limited  to  one  or  three  days, 
there  is  considerable  difference  in  target  kill  performance 
especially  when  the  probability  of  good  CH  conditions  is  low. 
As  the  time  allowed  approaches  ten  days,  the  difference  with  and 
without  forecast  is  less  pronounced,  because  either  way,  the  ten 
targets  are  eliminated  by  repeated  attack  over  the  extended  time 
allowed. 

SUMMARY  AND  CONCLUSIONS 

The  purpose  of  this  paper  is  to  describe  an  end-to-end  analysis 
and  modeling  process  that  traces  the  value  of  weather  forecast 
data  to  military  missions.  The  procedures  presented  herein 
include: 

•  simulation  of  temporally  and  spati ally-dependent 
weather  parameters  from  calibrated  ground 
sources  for  truth  and  satellite-simulated 
measurement  for  forecast 


The  numerical  results  set  forth  here  are  preliminary  in  that 
specific  mission,  weather  databases,  weapon  systems,  and 
CONOPs  are  employed.  The  procedures,  however,  have  broader 
application  potential.  These  techniques  can  be  refined  and 
extended  to  a  broad  variety  of  military  and  civilian  missions. 
Only  minor  modification  is  needed  to  address  differing  systems 
and  CONOPs. 
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•  statistical  characterization  of  forecast  weather 
parameter  error  in  space  and  time 

•  use  of  weather  parameter  data  to  create  cloud 
visibility  and  weapon  sensor  engagement 
performance  probabilities  for  an  air  munitions 
drop  mission 

•  use  of  nominal  weather  climatology,  forecast 
accuracy,  weapon  system  performance,  CONOPs, 
and  scenario  conditions  to  evaluate  mission 
MOEs  and  their  sensitivities  to  these  Measures  of 
Performance  (MOPs) 

•  exploration  of  MOE/MOP  sensitivities  to  set 
requirements  on  MOP  values 
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MULTIPLE  HYPOTHESIS  TRACKING  vs  KALMAN  FILTER  WITH  NEAREST 
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Summary 

Multi-target  tracking  systems  in  operational  use  today 
generally  adopt  standard  Kalman  filter  techniques, 
coupled  with  a  maneuver  detector  to  introduce  some 
kind  of  adaptivity,  and  nearest  neighbor  (NN) 
correlation  with  a  plethora  of  heuristics  to  improve  the 
performance  of  the  system.  Through  Monte  Carlo 
simulations,  the  performance  of  a  multiple  hypothesis 
multi-target  tracking  algorithm  were  evaluated  in 
terms  of  the  probability  of  correct  association  of  a  track 
to  a  target.  The  performance  of  a  Kalman  filter  plus 
NN  is  used  as  reference.  Results  are  presented  for  a 
number  of  study  cases  related  to  several  operational 
situations  of  interest  (e.g.  up  to  eight  targets 
undergoing  maneuvers).  A  preliminary  evaluation  of 
the  processing  time  ensures  that  the  MHT  algorithm 
can  be  implemented  in  modem  computers  having 
adequate  processing  power. 

1.  Introduction 

Multi-target  tracking  systems  in  operational  use  today 
generally  adopt  standard  Kalman  filter  techniques, 
coupled  with  a  maneuver  detector  to  introduce  some 
kind  of  adaptivity,  and  nearest  neighbor  correlation 
with  a  plethora  of  heuristics  to  improve  the 
performance  of  the  system  [1,2].  Limitations  of  such 
an  approach  are  analyzed  in  [3]  and  can  be 
summarised  in  the  limited  performance  in  presence  of 
spurious  measurements  and  in  the  unavoidable 
compromise  between  two  contrasting  requirements,  i.e. 
good  filtering  of  measurement  noise  and  promptness  in 
following  sharp  maneuvers.  The  necessity  of  ensuring 
track  continuity  under  critical  conditions,  like  rapidly 
maneuvering  targets  in  presence  of  natural  and/or 
intentional  disturbances  in  high  target  density 
scenarios,  requires  more  sophisticated  correlation  and 
association  algorithms.  They  are  JPDA  (Joint 
Probabilistic  Data  Association)  [4]  and  MHT  (Multiple 
Hypothesis  Tracking)  [5,6]  which  in  the  recent  past 
were  considered  unaffordable  because  of  their  high 
computational  and  memory  requirements.  Now  they 
can  be  reconsidered  in  view  of  the  continuous 
advances  in  computer  technology  (like  powerful 
workstations  and  parallel  computers).  These 
algorithms,  combined  with  a  multiple  model  approach, 
where  several  dynamic  models  are  postulated  for  the 
target,  represent  viable  and  effective  solutions  to  the 
problem.  MHT  specifically  is  recognized  as  the 
theoretically  best  approach  to  the  multi-target  tracking 


problem.  It  includes  the  implementation  of  a  multi¬ 
scan  correlation  algorithm  which  delays  decision  on 
the  association  of  plots  to  targets  so  as  to  exploit 
subsequent  information.  It  also  offers  the  possibility  of 
trading-off  computational  requirements  with  algorithm 
performance.  [5]  is  a  pioneering  work  on  multiple 
hypothesis  tracking.  Other  sub-optimal 
implementations  can  be  found  in  [6]  to  [9]. 

The  purpose  of  this  paper  is  to  provide  a  comparison 
between  traditional  tracking  algorithms  and  a  sub- 
optimal  implementation  of  the  MHT  algorithm  in 
terms  of  track  maintenance  capability,  i.e.  the 
probability  of  not  loosing  or  not  switching  tracks. 

This  paper  is  organized  as  follows.  Section  2  provides 
a  brief  description  of  the  MHT  theory.  In  section  3  the 
software  details  of  our  sub-optimal  implementation  are 
described.  Simulation  results  relative  to  specific  study 
cases  are  presented  and  analyzed  in  section  4. 

Finally,  section  5  gives  a  feeling  of  the  computational 
requirements  of  the  algorithm  and  hints  on  future 
work. 

2.The  MHT  algorithm 

MHT  is  recognized  as  the  theoretically  best  approach 
to  the  multi-target  tracking  problem,  yet  it  requires  a 
considerable  amount  of  computation  and  memory 
resources.  A  practical  MHT  implementation  can  be 
obtained  by  limiting  the  depth  of  the  multi-scan 
correlation  and  by  adopting  several  other  techniques 
which  limit  processing  requirements.  In  the  sub- 
optimal  implementation  of  the  MHT  described  here  we 
have  followed  the  track  oriented  approach  [8],  which  is 
more  flexible  and  efficient  and  also  intuitively  more 
appealing  than  the  measurement  oriented  approach 
[5].  In  the  track  oriented  approach,  each  target  can  be 
depicted  (see  figure  1)  as  a  tree,  where  the  root  of  the 
tree  represents  the  birth  of  the  target,  and  the  branches 
represent  different  track  hypotheses  for  the  target.  At 
each  scan,  new  branches  are  formed  corresponding  to 
the  different  dynamic  models  for  the  target  (constant 
velocity  or  maneuver  model)  [10].  Then  each  branch  is 
further  expanded  to  account  for  feasible  associations 
with  the  plots  in  the  scan  or  a  missed  detection.  A 
trace  of  successive  branches  from  the  root  to  a  leaf  of 
the  tree  corresponds  to  a  potential  track  (hypothesis) 
for  the  target.  A  likelihood  value,  measuring  how  well 
the  sequence  of  reports  matches  the  hypothesis,  can  be 
computed  for  each  potential  track.  A  global  hypothesis 
(see  figure  1)  is  formed  by  combining  tracks  from 
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different  target  trees  picking  at  most  one  track  from 
each  target  tree.  Assuming  one  return,  at  most,  per 
target  per  scan,  then  tracks  forming  a  feasible  global 
hypothesis  should  not  share  the  same  returns. 


Figure  1.  Feasible  global  hypotheses  from  two  trees 
related  to  targets  T1  and  T2  and  built  with  plots  Ri. 

Likelihoods  of  the  global  hypotheses  are  then 
evaluated  from  the  likelihoods  of  the  tracks  (see 
ensuing  Section  2.1).  The  global  hypothesis  with  the 
highest  likelihood  is  selected  and  used  to  identify  the 
most  likely  set  of  branches  for  each  target  N  scans 
before  the  actual  scan.  The  unlikely  branches  are 
pruned  away  (see  figure  2).  This  retrospective 
procedure  (N-scanback  approximation)  solves  the 
multiple  plot-to-target  association  problem. 

Compare  now  MHT  with  JPDA  algorithm.  JPDA  can 
be  considered  as  a  zero-scan  algorithm.  It  tends  to 
coalesce  closely  spaced  targets.  It  is  not  always  easy  to 
incorporate  in  the  JPDA  algorithm  a  priori 
information  such  as,  for  instance,  the  target  identity.  It 
has  a  relatively  large  computational  requirement.  In 
principle  JPDA  requires  the  calculation  of  the 
probability  of  all  the  global  hypotheses;  each 
probability  is  used  to  weigh  the  correlating  plots  that 
update  the  system  track.  On  the  contrary,  MHT  needs 
to  detennine  only  the  most  likely  global  hypothesis  and 
this  can  be  achieved  without  going  through  all  the 
global  hypotheses  as  JPDA  does  [8]. 


Most  likely 
Global 


Figure  2. 2-scan  approximation  technique  applied  to 
target  trees  T1  and  T2  (M  stands  for  missed  detection). 

2.1  Evaluation  of  global  hypothesis  likelihood 

The  purpose  of  this  section  is  to  give  the  mathematical 
expression  of  the  probability  of  the  global  hypothesis. 
Consider  the  following  set  of  radar  measurements: 

where  z(k)  is  the  set  of  radar  measurements  at  the  k-th 
scan  and  ^  is  the  set  of  radar  measurements  up  to  the 
k-th  scan.  Indicate  with 

a  set  of  hypotheses,  where  q\  is  the  i-th  association 
hypothesis  up  to  the  k-th  scan,  q-  (A:)  is  the  i-th 
hypothesis  associating  plots  and  targets  at  the  k-th 
scan  and  q^^^  is  the  1-th  association  hypothesis  up  to 

the  (k-l)-th  scan  from  which  the  i-th  association 
hypothesis  derives.  It  can  be  shown  [8,11]  that  the 
following  equation  applies: 
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where: 

C  is  a  constant: 

— >.7.K(z,Wl9*)]j 

and 

t=number  of  postulated  targets; 

r=number  of  plots  received  at  the  current  scan; 

%=number  of  terminated  targets; 

d=number  of  detected  targets  from  (t-x)  non> 

terminated  targets; 

m=number  of  maneuvering  targets; 

b=number  of  bom  targets; 

=  probability  of  target  termination; 

=  probability  of  target  detection; 

P^  =z  probability  of  maneuvering  target; 

X  expected  number  of  false  alarms  in  one  scan; 

X-  ^  =  expected  number  of  bom  targets  in  one  scan; 

Ptm  ( )  =  conditional  likelihood  that  the  received  plots 
are  originated  from  a  maneuvering  target; 

Pts  ( )  =  conditional  likelihood  that  the  received  plots 
are  originated  from  a  non-maneuvering  target; 

Pb  ( )  =  conditional  likelihood  that  the  received  plots 
are  originated  from  bom  targets; 

Pfa  ( )  =  conditional  likelihood  that  the  received  plots 
are  originated  from  false  alarms; 

Tm  =  set  of  plots  associated  with  maneuvering  and 
detected  targets; 

Td-m  =  set  of  plots  associated  with  non-maneuvering 
and  detected  targets; 

Tb  =  set  of  plots  associated  with  bom  targets. 

The  previous  equation,  which  is  recursive  in  nature, 
updates  the  global  hypothesis  likelihood  by  the  product 
of  five  terms  which  correspond  to  five  independent 
events.  These  events  are  respectively  related  to 


terminating  targets,  non  detected  targets,  maneuvering 
targets,  non  maneuvering  targets  and,  finally,  bom 
targets.  The  false  alarm  event  is  represented  in  the  last 
three  events  and  in  the  constant  term  via  the  quantities 
X  and  Pfa  ( ).  The  equation  above  determines  the 

most  likely  global  hypothesis  which  is  selected  to 
update  the  system  tracks. 

2.2  Hypothesis  reduction  techniques 

Techniques  have  been  devised  to  reduce  the  number  of 
hypotheses  to  a  manageable  level.  They  are  as  follows. 
gating:  it  is  performed  to  reduce  the  number  of  plots 
which  correlate  with  the  track.  This  is  implemented,  as 
usual,  by  calculating  the  distance  (also  referred  to  as 
statistical  innovation)  between  plot  and  predicted 
position  of  track  and  comparing  the  distance  with  a 
threshold  via  a  proper  metric.  More  precisely,  three 
gates  are  built  around  the  predicted  position  of  the 
track;  the  inner  two  ones  serve  the  purpose  of 
detecting,  with  variable  degree  of  confidence,  a  target 
maneuver,  while  the  outermost  gate  limits  the  region 
to  be  searched  for  the  plots  originated  from  a 
maneuvering  target. 

track  hypothesis  updating:  maneuver  branches  are 
created  only  if  a  maneuver  is  detected:  a  maneuver  is 
modeled  as  a  random  process  by  increasing  the 
prediction  error  covariance  matrix  (see,  for  details,[l] 
Section  4.3.1).  A  missed  detection  hypothesis  is 
formulated  when  the  following  events  occur:  no  plot 
falls  inside  the  two  inner  gates  or  plot  falls  inside  the 
two  inner  correlation  gates  but  it  correlates  with  more 
than  one  track. 

clustering:  tracks  are  grouped  in  clusters,  each 
including  only  tracks  which  compete  in  the  assignment 
process.  This  transforms  the  original  assignment 
problem  into  several  uncoupled  problems  of  lower  size, 
thus  limiting  the  exponential  growth  in  number  of  the 
global  hypotheses. 

N-scanback  approximation:  it  limits  the  depth  of  the 
multi-scan  correlation  (see  Section  2  and  figure  2). 
tree  pruning:  it  limits  the  number  of  track  hypotheses 
per  target  tree  to  the  M  most  likely. 

The  gate  sizes,  together  with  N  and  M,  i.e.  the  values 
of  the  scanback  and  tree  pruning  parameters,  are 
examples  of  user  definable  parameters  which  can  be 
selected  to  control  the  trade-off  between  performance 
and  computation  requirements. 

3.Description  of  tracking  testbed 

The  purpose  of  this  section  is  to  describe  the  flow¬ 
chart  of  the  implemented  software,  the  choice  of  data 
structures  managed  by  the  program  and  of  the  software 
language,  and  the  graphical  facilities  provided  by  the 
testbed. 

3.1  Flow-chart 

A  flow-chart  of  the  implemented  software  is  shown  in 
figure  3. 
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Block  I  It  performs  conventional  processing  functions 
(gating  and  maneuver  detection)  that  are  typical  of 
tracking  algorithms. 

Block  2  New  track  hypotheses  (i.e.  the  branches  of  a 
target  tree)  are  formed  on  the  basis  of  the  new 
correlating  plots. 

Block  3  The  track  likelihood  is  calculated  according  to 
the  equation  introduced  in  Section  2.1. 

Block  4  It  limits  the  maximum  number  of  branches  per 
tree. 

Block  5  When  a  missed  detection  hypothesis  is 
formulated  (see  Section  2.2,  track  hypothesis 
updating),  a  new  branch  is  generated  in  the  target  tree. 
Block  6  The  clustering  function  is  implemented  as 
described  in  Section  2.2. 

Block  7  The  most  likely  global  hypothesis  is  extracted 
with  an  ad  hoc  algorithm  that  avoids  the  screening  of 
all  the  feasible  global  hypotheses;  all  branches  which 
do  not  pertain  to  the  selected  global  hypothesis  are 
pruned  as  shown  in  figure  2. 

Block  8  The  Kalman  filter  algorithm  is  recursively 
applied  to  all  the  tracks  that  survived  after  the  pruning. 
See  track  hypotheses  represented  with  bold  and  light 
lines  in  figure  2. 

The  software  design  exploits  the  representation  of 
track  hypotheses  and  plot-track  correlation  via  logical 
trees  and  branches,  respectively.  Thus  the  multi-scan 
correlation  problem  is  coded  in  the  software  by 
operating  on  tree  data  structures.  The  software  has 
been  written  in  C.  The  C  language  has  been  chosen  for 
its  efficient  handling  of  complex  data  structures, 
dynamic  storage  allocation  and  recursion  (e.g. 
manipulation  of  tree  structures).  The  software  resulted 
in  a  few  thousand  lines  of  code.  The  testbed  is 
implemented  on  a  SUN  Sparc  2  workstation. 

3.2  The  interface 

A  very  attractive  feature  of  the  testbed  is  the  graphical 
interface  which  has  proven  very  useful  to  analyze  and 
gain  insight  into  the  problem.  This  interface  is 
implemented  using  the  X-Window  library.  Buttons 
make  it  possible  to  control  the  progress  of  the 
simulation  on  a  scan-by-scan  basis,  and  select  data  to 
be  displayed.  The  interface  also  allows  an  easy  build¬ 
up  of  scenarios  to  be  tested;  it  provides  the  output  of 
results  and  statistics  in  a  graphical  form.  A  snapshot  of 
the  display  is  provided  in  fig.  4.  The  display  shows  38 
buttons  corresponding  to  many  functions  that  can  be 
activated  with  the  mouse.  For  instance,  the  button 
Temp  corresponds  to  a  processing  mode  that  visualizes 
how  the  tracks  evolve  in  a  scan-to-scan  fashion.  The 
most  likely  track  hypotheses  and  all  the  other  tentative 
hypotheses  are  depicted  together  with  the  ellipsoidal 
correlation  gates.  Figure  5  is  an  example  of  the  target 
speed  vs  time;  there  are  two  curves,  one  corresponds  to 
the  true  target  speed  while  the  other,  lagging  behind, 
refers  to  the  target  speed  estimated  by  the  MHT 
tracking  filter. 
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Figure  3.  Flow-chart  of  the  MHT  algorithm. 

4.Description  of  simulation  results 

The  performance  of  the  MHT  multi-scan  algorithm  is 
compared  with  that  of  a  traditional  zero-scan  Kalman 
filter  which  updates  the  track  with  that  plot  having  the 
minimum  statistical  distance  (i.e.  NN  logic)  from  the 
track  predicted  position.  Association  ambiguities  are 
resolved  by  making  the  best  overall  selection  of  plot- 
track  pairings.  The  target  state  vector  comprises 
position  and  velocity  along  the  x  and  y  coordinate 
axes;  process  noises  along  the  direction  parallel  and 
perpendicular  to  the  speed  are  modeled  as  mutually 
independent,  zero-mean,  white  Gaussian,  random 
sequences  and  the  ratio  of  their  variances  is  1:9.  Both 
tracking  filters  (i.e.  the  MHT  multi-scan  and  the  NN 
zero-scan)  are  equipped  with  the  same  target  maneuver 
detector  and  adaptation  of  tracking  filter  parameters 
(see,  for  details,  [1]  Section  4.3.1).  The  radar  is  always 
located  in  the  origin  of  the  Cartesian  coordinate 
reference  system  and  it  provides  range  and  azimuth 
measurements  with  standard  deviation  errors  of  50  m 
and  3.4  mrad  respectively.  The  radar  scan  rate  is  2  s. 
Each  plot  is  detected  with  a  detection  probability  Pd 
which  is  a  parameter  of  the  tracking  simulation  trial. 
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A  single  plot  is  received  when  targets  fall  in  the  same 
radar  resolution  cell.  Sometimes,  false  plots  due  to 
clutter  are  randomly  generated  within  a  certain  sector. 
Results  provide  the  probability  of  loosing/switching  a 
track  against  the  value  of  Pd  for  each  of  the  algorithms 
under  consideration.  One  thousand  Monte  Carlo  runs 
have  been  executed  for  each  experiment. 

4.1  Purpose  of  the  simulation 

Phirpose  of  the  simulation  is  to  analyze  both  quality 
scenarios  (i.e.  few  highly  maneuvering  targets,  flying 
in  sectors  with  heavy  clutter,  whose  trajectories  have 
been  chosen  so  as  to  highlight  specific  performance 
and  behaviours  of  the  tracking  system)  and  also  a 
dense  scenario  where  an  average  figure  of  performance 
is  extracted.  The  following  subsections  describe  in 
details  for  each  scenario  the  achieved  performance 
results. 

4.2  Two  crossing  targets 

The  simplest  problem  which  can  be  considered  in 
multi-target  tracking  is  depicted  in  Fig.  6a.  Two 
targets  fly  along  intersecting  straight-line  paths  at  a 
speed  of  250  m/s.  Paths  intersect  midway  through  the 
50-scan  flight  duration  forming  an  angle  of  4.6 
degrees.  In  this  situation,  the  consequence  of  incorrect 
correlations  is  the  so-called  "track-switching" 
phenomenon.  The  probability  of  track  switching  is 
drawn  in  figure  6b  versus  the  probability  of  detection 
Pd.  For  the  classical  tracking  filter,  the  track  switching 
probability  increases  as  the  Pd  value  reduces  from  1  to 
0.6,  while  it  remains  practically  constant,  at  a  lower 
value,  for  the  multi-scan  algorithms.  In  particular  the 
2-scan  algorithm  provides  a  significant  performance 
improvement. 

4.3  Two  targets  joining  and  diverging 

In  this  scenario  targets  maneuver  and  separate  rather 
than  crossing.  The  kinematic  characteristics  of  the 
target  paths  are  the  following.  Targets  start  moving 
along  two  straight  lines  with  components  of  velocity  of 
100  m/s  on  the  x  and  y  axes;  subsequently  targets 
perform  a  90  degrees  turn  with  maneuver  acceleration 
of  3g.  The  minimum  distance  between  the  two  tracks 
is  approximately  200  m  (see  figure  7a).  Figure  7b 
shows  the  achieved  results  in  terms  of  the  probability 
of  track  switching  versus  the  value  of  Pd,  for  the  three 
algorithms  tested.  The  zero-scan  algorithm 
implements  a  filter  with  a  relatively  slow  reaction 
time.  For  this  reason,  as  the  targets  converge  and  start 
maneuvering,  targets  tend  to  maintain  their  course  and 
so  the  probability  of  crossing  each  other  is  very  high. 
On  the  contrary  multi-scan  algorithms  generate  a 
maneuver  hypothesis  which  follows  the  target 
maneuver  with  great  promptness;  thus,  they  are  able  to 
successfully  resolve  the  scenario.  This  scenario  is  very 
tricky  because  targets  separate  with  an  angle  identical 
to  the  one  they  form  in  the  converging  portion  of  the 
experiment.  In  fact,  delaying  the  association  decision 


for  a  few  scans  does  not  greatly  reduce  the  association 
uncertainty.  This  explains  why  the  2-scan  algorithm, 
coupled  with  a  maneuver  detector  which  does  not 
estimate  the  acceleration,  does  not  provide  any 
increase  in  performance  over  the  1-scan  algorithm 
when  Pd=l.  Of  course,  the  performance  rapidly 
deteriorates  as  the  Pd  value  reduces  from  1  to  0.6.  For 
Pd  values  lower  than  1,  a  few  missed  detections  in  the 
critical  portion  of  the  scenario  would  make  it 
impossible,  even  for  a  well  trained  operator,  to  resolve 
the  trajectories  correctly. 

4.4  Target  in  a  looping  maneuver 

This  scenario  stresses  the  response  of  the  filter  in 
presence  of  a  longitudinal  maneuver.  Actually  it 
models  (see  figure  8a)  a  target  performing  a  loop  in 
the  vertical  plane.  This  maneuver  is  described,  in  the 
x-y  plane,  as  a  change  of  target  velocity  from  +300  to  - 
300  m/s  with  a  longitudinal  acceleration  of  -3g  and 
with  an  additional  change  of  target  velocity  from  -300 
to  +300  m/s  with  a  longitudinal  acceleration  of  +3g. 
The  corresponding  probability  of  loosing  the  track  is 
depicted  in  figure  8b.  As  usual,  the  MHT  multi-scan 
algorithm  provides  a  performance  advantage  over  the 
classical  zero-scan  tracking  algorithm  for  Pd  values 
lower  than  1. 

4.5  Straight-line  target  in  a  clutter  area 

A  target  following  a  straight-line  path  (see  figure  9a) 
at  a  rate  of  300  m/s  crosses  a  clutter  bank  of  extension 
3  km  (along  x)  per  8  km  (along  y).  The  number  of 
scans  in  which  the  target  plot  is  within  the  clutter 
region  is  5.  A  global  number  of  35  clutter  plots  are 
uniformly  distributed  within  the  above  mentioned 
sector  and  this  corresponds  to  a  density  of  clutter  plots 
of  1.5/km^.  The  performance  criterion  is  the 
probability  of  successfully  traversing  the  clutter  region. 
Such  a  capability,  when  compared  with  the  poor 
performance  of  the  NN  algorithm,  arises  from  the 
inclusion  of  knowledge  of  clutter  maps  in  the  equation 
evaluating  the  track  likelihood  (see  Section  2.1).  The 
probability  of  loosing  the  track  is  portrayed  in  Figure 
9b.  When  Pd=l,  miscorrelation  occurs  when  a  clutter 
plot  falls  closer  to  the  track  predicted  position  than  the 
true  plot  originated  by  the  target.  This  probability  is 
very  low  with  the  current  clutter  density,  and  this 
explains  why  the  track  successfully  traverses  the 
clutter  region  with  a  very  high  probability  when  Pd=l. 
With  lower  values  of  the  target  detection  probability 
Pd,  the  miscorrelation  event  has  a  higher  probabihty; 
yet  the  hypotheses  postulating  a  missed  detection  are 
not  unlikely  compared  to  all  other  hypotheses  and  this 
allows  the  MHT  to  bridge  over  spurious  measurements 
and  maintain  the  straight-line  flight  path. 

4.6  Maneuvering  target  in  clutter 

This  scenario  investigates  the  capability  of  the  tracking 
algorithm  to  follow  a  maneuvering  target  in  clutter. 
Figure  10a  shows  the  target  which  is  moving  on  a 
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Straight  line  path  with  components  of  velocity  along 
both  Cartesian  axes,  equal  to  220  m/s.  When  the  target 
enters  a  square  clutter  region  of  6  by  6  km,  it  performs 
a  turn  of  180°  with  a  centripetal  acceleration  of  5g.  A 
number  of  6  false  plots  are  uniformly  distributed  in  the 
clutter  region  corresponding  to  a  density  of  clutter 
plots  of  0.2/km^.  The  probability  of  loosing  the  track 
is  shown  in  figure  10b.  As  expected,  the  NN  zero-scan 
algorithm  shows  a  very  reduced  capability  to  follow 
the  target  in  clutter.  On  the  contrary,  the  multi-scan 
ensures  a  certain  capability  to  track  the  target  even 
though  its  performance  is  poor  for  low  values  of  Pd. 

4.7  Dense  scenario 

Figure  11a  shows  a  dense  scenario  with  eight  targets: 
five  targets  move  along  straight  line  paths  with 
velocity  values  in  the  order  of  200  m/s;  the  remaining 
three  targets  undergo  maneuvers  with  acceleration 
values  between  3g  and  5g.  The  duration  of  the 
acceleration  is  in  the  order  of  ten  radar  scans 
approximately.  The  interaction  between  at  least  two 
and  up  to  four  targets  occurs  a  number  of  times  during 
the  temporal  evolution  of  the  operational  scenario.  Fig. 
1  la  displays  the  temporal  sequence  of  plots,  pertinent 
to  the  eight  targets,  in  the  case  of  radar  detection 
probability  equal  to  one.  The  same  figure  shows  the 
corresponding  tracks  (continuous  lines)  produced  by 
the  MHT  algorithm  with  1-scanback.  To  appreciate  the 
performance  comparison  between  the  MHT  and  the 
NN  zero-scan  algorithm,  figure  1  lb  has  been  prepared. 
To  limit  the  computational  time,  the  MHT  was  set  up 
to  maintain  just  the  best  ten  hypotheses  per  target  tree 
and  no  significant  performance  loss  was  noticed.  The 
numerical  values  depicted  in  the  figure  represent  the 
summation  of  the  lost  and  switched  tracks  in 
percentage.  Indeed  the  MHT  algorithm  provides  a 
useful  service  and  the  performance  gain  is  more 
evident  for  low  values  of  Pd.  The  greatest 
improvement  is  between  the  zero-scan  and  the  1-scan 
solutions.  This  experimental  observation,  together  with 
the  consideration  that  the  processing  requirements  of 
the  algorithm  grow  exponentially  with  the  scanback 
parameter,  suggests  that  at  the  moment  the  1-scan 
algorithm  has  a  greater  performance  to  computational 
requirements  ratio. 

S.Concluding  remarks 

To  give  an  idea  of  the  computational  time  required  by 
the  MHT,  a  not  optimized  software  implementation  of 
the  algorithm,  running  on  a  SUN  SPARC  2  work 
station,  gives  the  following  figures:  the  computational 
time  per  scan  (remind  the  number  M  of  track 
hypotheses  per  target  tree  was  set  to  10)  for  the 
operational  environment  studied  in  section  4.7  is  40 
ms.  (0-scanback),  80  ms.  (1-scanback)  and  160  ms.  (2- 
scanback).  Thus  the  algorithm  could  process  in  real 
time,  say,  200  targets  flying  in  clusters,  each  cluster 
containing  up  to  four  targets,  working  with  the  2- 
scanback  strategy  and  a  radar  scan  rate  of  4  s.  This 


performance  can  be  greatly  improved  by  running  the 
algorithm  on  faster  commercially  available  machines 
rather  than  on  the  SUN  Sparc  2. 

In  the  next  future,  we  intend  to  extend  the  capability  of 
the  algorithm  to  handle  additional  data  (range  rate, 
elevation  angle,  target  identity)  and  also  introduce 
more  sophisticated  target  models,  e.g.  replacing  the 
target  state  model  with  an  augmented  sixth-order 
model  (which  estimates  acceleration)  only  for  the 
duration  of  the  maneuver.  Optimization  of  processing 
time  is  another  topic  of  investigation.  Additional  areas 
of  future  work  refer  to  the  processing  of  recorded  live 
data,  the  extension  of  the  MHT  algorithm  to  the 
multisensor  tracking  case  and  mapping  of  the 
algorithm,  which  is  inherently  parallel,  on  to  a 
network  of  workstations. 
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Figure  4.  Typical  display  from  MHT  algorithm, 
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Figure  6a.  Two  straight-line  crossing 
targets. 


Figure  6b.  Probability  of  switching 
the  two  targets. 
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Figure  7a.  Two  non-crossing  targets. 


Figure  7b.  Probability  of  switching 
the  two  targets. 
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Figure  8a.  Straight-line  target  with  looping  Figure  8b.  Probability  of  loosing  the 
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Figure  9a.  Straight-line  target  in  clutter. 


Figure  9b.  Probability  of  loosing  the 
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Abstract 

The  hardware  prototype  of  a  MIMD  (multiple  instruc¬ 
tion  multiple  data)  computing  machine  dedicated  to  the 
processing  of  large  amounts  of  data  in  real  time  is  de¬ 
scribed.  The  Lattice  Automata  Machine  (LAM)  is  based 
on  a  cellular  automata  architecture,  but  has  extended  fea¬ 
tures  as  for  example  ’’non-local”  and  ’’time  dependent” 
programming.  The  front  end  of  LAM  is  hosted  in  a  per¬ 
sonal  computer,  used  as  an  input-output  peripheral.  This 
machine  has  been  developed  for  dedicated  programming 
of  systems  of  partial  differential  equations  and  processes 
up  to  1.15  Giga  events  per  second.  One  of  the  hardware 
characteristics  introduced  in  this  machine  is  the  possibil¬ 
ity  of  memory  replication  in  different  data  banks,  enabling 
the  simultaneous  access  to  different  RAM  positions. 

1  -  Introduction 

Large  scale  computing  is  a  necessity  in  engineering, 
basic  research  and  computer  assisted  decision  making, 
[3],  [7],  [8]  and  [10]. 

Multicomponent  real  systems  are  extended  in  space 
and  evolve  in  time  according  to  the  evolution  laws  of 
individual  subsystems  and  to  the  interactions  with 
local  and  nonlocal  neighbours,  fig.  1. 


Figure  1:  Spatial  distribution  of  an  extended  system 
and  interaction  laws  with  local  and  nonlocal  neigh¬ 
bours. 

Data  characterizing  subsystems  at  time  t  depend  of 
data  of  several  neighbour  subsystems  at  time  ^  —  1. 
The  performance  of  computing  machines  to  calculate 
time  evolution  of  extended  systems  is  low  due  to  the 
sequential  order  in  which  data  are  collected  for  calcu¬ 
lations.  In  real  systems  time  evolution  is  intrinsically 
parallel,  in  the  sense  that  the  whole  system  is  updated 
in  one  real  time  step,  and  each  subsystem  can  use  the 
information  of  other  subsystems  simultaneously. 

Vectorial  or  multiprocessor  machines  achieve  com¬ 
puting  performance  by  grouping  together  indepen¬ 
dent  computing  steps  and  vectoring  independent  data 
sets,  reducing  the  number  of  sequential  clock  cycles. 


and  consequently  the  overall  computing  time.  How¬ 
ever,  the  simultaneous  access  to  data  sets  is  not  pos¬ 
sible,  and  this  is  a  critical  path  in  computation. 

The  objective  of  this  paper  is  to  show  that  com¬ 
puter  performance  is  increased  by  a  different  orga¬ 
nization  of  the  data  available  for  computing,  trans¬ 
forming  dynamically  every  distributed  system  into  a 
local  system.  Every  distributed  system  can  be  trans¬ 
formed  into  a  local  system  trough  the  replication  of 
data  in  memory  (redundancy),  enabling  the  simul¬ 
taneous  access  to  different  memory  positions.  Under 
these  conditions,  the  advantages  of  parallel  and  vecto¬ 
rial  processing  lead  to  much  faster  computations  when 
compared  with  traditional  machines. 

The  increase  of  data  memory  leading  to  redun¬ 
dancy,  the  independence  of  program  memory  from 
data,  and  the  introduction  of  parallel  computing  en¬ 
ables  real  time  computing,  achieving  1.15  Giga  events 
per  second  in  a  small  machine.  The  enhancement  of 
computing  time  obtained  by  replicating  input  data 
permits,  virtually,  the  simultaneous  access  to  differ¬ 
ent  RAM  positions. 

The  architecture  we  propose  has  been  developed 
to  solve  problems  such  as  war  games,  fluid  flow,  fire 
propagation,  image  processing  and  multiparticle  dy¬ 
namics.  All  these  problems  have  in  common  the  fact 
that  the  individual  elements  are  distributed  in  a  two- 
dimensional  space  (a  plane),  and  evolve  in  time  ac¬ 
cording  to  some  dynamic  law,  described  by  the  func¬ 
tional  equation 


^  ^ 

\  ’  dy^  ’  ’  dtdx  ’  dtdy  ’  dxdy  ’ 

d<j)  d<j)  d(j) 
dx^  dy'‘  dt 


d<j>  d4>d(j} 
dx’dv’ 


(1) 


where  x^y  and  t  are  space  and  time  variables  and 
(f){x,y,t)  represents,  for  example,  the  velocity  field 
in  a  fluid  or  the  distribution  of  individuals  in  two 
opponent  armies.  The  conversion  from  the  func¬ 
tional  form  (1)  to  a  discrete  form  is  done  by  the 
usual  finite  differences  approximations,  as  for  exam¬ 
ple,  1^  (^j+i  -h  -  2</),)/(A.t)^. 

The  most  important  characteristics  of  the  hardware 
prototype  described  here  are: 

1)  Parallel  calculations  in  multidimensional  spaces, 
accessing  up  to  18  local  and  non-local  neighbours, 
with  the  same  performance. 
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2)  Total  independence  of  data  and  program  memory 
buses. 

3)  Capability  to  perform  dependent  or  independent 
tasks,  partitioning  base  memory,  program  memory 
and  program  control  units. 

4)  Dedicated  display  independent  from  the  front  end. 

5)  The  programming  language  is  C,  adapted  to  the 
specific  abstract  machine  model.  The  front  end  is 
hosted  in  a  personal  computer. 

6)  Direct  implementation  of  systolic  arrays. 

To  simplify  this  exposition,  we  now  consider  a  class 
of  systems  having  a  simple  implementation  under  the 
general  computing  scheme  presented  here.  In  the  last 
section,  the  characteristics  and  the  basic  architecture 
of  the  hardware  prototype  is  described. 

2  -  A  cellular  automata  model 

Since  the  work  of  von  Newman  on  self- replicating 
machines  [2],  [9],  cellular  automata  played  an  impor¬ 
tant  role  in  theoretical  computer  science.  Recently, 
cellular  automata  models  have  become  popular  with 
the  work  of  S.  Wolfram  [11]  on  its  potential  applica¬ 
tions  in  physical  sciences.  The  possibility  to  explain 
the  emergence  of  complex  structures  from  very  simple 
rules,  simply  based  on  the  algebra  of  logics,  seems  to 
be  a  promising  field  of  research. 

As  in  Turing  machines,  cellular  automata  are  arrays 
of  memory  positions  that  hold  symbols  from  an  al¬ 
phabet.  The  symbols  in  each  memory  position  evolve 
in  time  according  to  some  local  rule.  These  systems 
simulate  an  universal  Turing  machine,  as  the  popular 
game  of  life  [1]. 

The  simplest  example  of  a  cellular  automata  is  ob¬ 
tained  with  an  infinite  strip  that  holds  zeros  and  ones. 
The  state  of  the  strip  at  time  ^  is  a  bi-infinite  se¬ 
quence  of  symbols.  At  time  i-f  1,  the  sequence  evolves 
according  to  the  local  rule 

where  /  is  some  boolean  function  and  xi  is  the  value 
of  the  boolean  variable  at  position  i.  For  example, 
figure  2  represents  an  evolving  configuration  for  an 
initial  finite  string  with  the  rule  f(x\_i^xl^xl^^)  = 

^  w 
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Figure  2:  Time  evolution  of  a  cellular  automata 
in  a  finite  array  with  periodic  boundary  conditions. 
Time  evolution  is  calculated  with  the  boolean  func¬ 
tion  f(xl_i,x\,xl^^)  =  We  represent 

the  read-write  moving  head  that  holds  the  informa¬ 
tion  on  the  state  of  the  processor. 


To  calculate  the  time  evolution  of  the  string  of  bits 
from  the  string  state  at  time  t  to  t  +  1,  the  machine 
head  performs  five  moves  to  update  each  site.  If  n  is 
the  length  of  the  strip  holding  the  information,  and  m 
is  the  breadth  of  the  boolean  function  /,  the  number 
of  elementary  steps  to  actualize  the  strip  from  time 
t  =  0  to  time  f  =  /c  is 


Elementary  steps  =  k{2m  —  l)n  (2) 


Suppose  now  that  we  replicate  twice  all  the  infor¬ 
mation  in  the  initial  strip  according  to  the  rule  of 
figure  3. 


read-wrIte 
I  moving  head! 


""1 

1 

1 

0 

0 

1 

0 

1 

1 

^0 

1 

1 

1 

0 

0 

1 

0 

1 . 

1 

T 

0 

T 

1 

1 

~0 

T 

"o" 

t=0 


Figure  3:  Replication  of  initial  data  of  the  cellular 
automata  of  figure  2,  with  periodic  boundary  condi¬ 
tions. 

From  the  data  set  of  figure  3,  the  cellular  automata 
does  not  depend  on  the  immediate  neighbours,  and 
the  local  time  evolution  is  calculated  from  the  data 
in  the  actual  position  of  the  read-write  head,  leading 
to  a  much  faster  actualization  of  the  string.  For  a 
strip  with  n  positions  and  memory  replication  m  —  1, 
the  number  of  computing  steps  after  evolution  at  time 
t  —  k  is 


Elementary  steps  =.  kn  (3) 

Comparing  (2)  with  (3),  linear  replication  of  memory 
storage  enabled  an  linear  decrease  in  computing  time. 

In  this  simple  example  we  have  shown  that  it  is  pos¬ 
sible  to  obtain  an  increase  in  computer  performance 
by  the  replication  of  data  in  memory. 

3  -  War  games 

The  Lencaster’s  combat  models  for  two  armies  de¬ 
scribe  the  temporal  evolution  of  the  number  of  com¬ 
batants  of  opposite  armies  as  a  function  of  operational 
and  combat  losses  by  unit  of  time,  and  of  the  rein¬ 
forcement  rates.  These  models  do  not  incorporate 
information  about  tactical  disposition  on  the  battle 
field.  However,  spatial  effects  can  be  taken  into  ac¬ 
count  easily. 

To  restrict  our  discussion  we  take  the  situation  of 
two  guerrilla  troops.  Let  A  and  B  be  the  number  of 
combatants  of  the  two  guerrilla  troops  without  rein¬ 
forcement.  The  Lencaster  equations  [4]  for  the  time 
evolution  of  the  number  of  effectives  is 
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dt 

dt 


=  —aA  —  bAB 
=  —cB  —  dAB 


(4) 


where  the  parameters  a  and  c  are  operational  losses 
(in  general  a  and  c  are  close  to  zero)  and  b  and  d 
describe  the  interaction  between  the  two  forces.  For 
a  =  c  =  0,  the  phase  space  analysis  of  the  above 
system  of  equation  shows  that,  for  initial  troops  Aq  > 
0  and  Bq  >  0,  A  wins  if  Bq  H-  dAo/b  <  0,  and  B  wins 
if  Bq  +  dAo /b  >  0.  Incorporating  tactic  disposition, 
random  motions  in  the  battle  field  and  obstacles  into 
these  equations,  we  obtain 


where  Da  and  D b  are  the  mobility  coefficients  of  both 
troops,  and  D{x^y)  carries  the  information  concern¬ 
ing  landscape  and  geometry,  Eq.  (5)  can  be  eas¬ 
ily  extended  to  describe  the  evolution  of  any  combat 
arrangement,  including  conventional-conventional  or 
guerrilla- conventional  interactions  and  progression  in 
the  battle  field. 

For  D{x^y)  ~  1  (no  obstacles),  it  can  be  shown  [5] 
that  the  time  evolution  of  the  number  of  effectives  is 
given  by 

-  bAtAljBjj  + 

Dab  +  G2(A\  j)  +  GsiAl  j)) 

=  Blj  -  dAtAljBlj  + 

Dab  {GiiBlj)  +  G2(B‘,,)  +  G,(Blj)) 

(6) 

where  Dab  =  Da/ ma.x{DA,DB},  Dba  = 
D B /  BL1^x.{D A;  D b}  1  aiid 

GiiA'ij)  =  {A^-ij  +  ^i+i j  +  +  ^ij+i  ~ 

4Alj)/l2 

G2{A\j)  =  + 

G3{A\  j)  =  {A\_2  j  +  A\^2,i  +  +  Alj+2  ~ 

4Ay/96 

(7) 


The  indices  (z,j)  refer  to  space  location  (x,y)  = 
(zAx^jAx).  The  space  scale  of  the  system  is  Ax  ~ 
^4max{DA,  BBjAt,  and  At  is  chosen  according  to 
some  realistic  system  of  units,  determined  by  the  mo¬ 
bility  constants  Da  and  Ds- 


To  compute  the  time  evolution  of  system  (6),  we 
choose  two  independent  lattice  planes  associated  to 
each  force.  Each  lattice  point  carries,  for  example  16 
bit,  representing  the  number  of  effectives  at  that  posi¬ 
tion.  Given  an  initial  distribution  of  troops,  we  need 
to  analyse  twelve  neighbours  at  each  site,  then  cal¬ 
culate  the  interaction  with  the  elements  of  the  other 
group,  and  repeat  the  calculation  for  all  the  lattice 
points.  An  arrangement  for  the  fast  computation  of 
this  system  is  presented  in  fig.  4. 


Progtam 

memory 


Figure  4:  Geometric  arrangement  for  fast  computing 
of  the  system  (6).  Each  square  holds  a  bit  and  the 
vertical  string  in  the  (x,y)  plane  represents  the  num¬ 
ber  of  effectives  in  this  region. 

The  two  lattices  associated  to  each  troop  carry  the 
same  information.  So,  the  arithmetic  and  logic  unit 
(ALU  system)  picks  simultaneously  two  neighbouring 
points  in  A  and  two  neighbouring  points  in  B  and 
makes  the  calculations  according  to  (6).  The  choice 
of  neighbouring  points  is  selected  by  a  Program  Con¬ 
trol  Unit  according  to  the  instructions  in  the  Program 
Memory.  As  all  these  operations  are  done  in  parallel, 
we  obtain  a  very  performing  computing  system. 

According  to  the  hardware  implementation  of  the 
LAM,  we  calculate  the  number  of  effectives  of  the  two 
armies  in  a  grid  of  512  x  256  in  65.76  ms,  with  a  color 
display  proportional  to  the  number  of  effectives. 

4  -  Fluid  dynamics  models 

Following  the  basic  principles  developed  so  far,  we 
can  interact  with  the  LAM  and  calculate  fluid  flow 
and  fire  propagation  in  real  time. 

Figure  5  shows  the  time  evolution  of  a  pollution 
front  in  the  Tagus  Estuary.  The  geometry  of  the  estu¬ 
ary  was  taken  from  a  satellite  image  and  the  boundary 
has  been  drawn  over  the  scenery.  In  this  application 
we  have  introduced,  the  effect  of  tides,  constant  flux 
boundary  conditions  and  variation  of  the  magnitude 
of  the  velocity  field. 

The  fluid  flow  is  calculated  in  the  LAM.  From  the 
front  end  hosted  in  a  personal  computer  (PC),  we  can 
control  the  display  velocity,  pick  up  frames  for  further 
processing  in  the  PC,  and  introduce  and  change  data 
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conditions.  Figure  5  is  the  front  end  display  with  the 
fluid  flow  calculated  by  the  LAM  and  already  pro¬ 
cessed  in  the  PC. 


Figure  5:  Evolution  of  a  pollution  front  in  the  Tagus 
Estuary. 


5  -  The  hardware  prototype 

The  Lattice  Automata  Machine  has  been  con¬ 
structed  with  a  total  base  memory  of  1024  x  1024 
cells.  Each  cell  has  18  layers  with  one  bit  of  informa¬ 
tion,  fig.  6.  A  Base  Memory  block  (BM)  has  256  x  512 
bit  of  storage  memory.  Connecting  together  all  the 
BM  blocks  through  a  programmable  switch  (PSW), 
we  achieve  up  to  1024  x  1024  bit  per  layer. 

The  first  sixteen  basic  layers  have  two  Program 
Memories  per  layer  (PM)  and  eight  Program  Con¬ 
trol  Units  (PCU).  These  units  interpret  the  program 
instructions  in  the  PM  to  perform  the  access  to  the 
Base  Memory  (BM)  through  the  PSW  and  a  partic¬ 
ular  relative  displacement  on  the  coordinates  of  the 
BM  (defined  in  the  PM).  Two  more  layers  with  inde¬ 
pendent  PM  are  defined  for  control  purposes.  Each 
PM  can  store  up  to  64K  time  dependent  programming 
instructions. 


□□□□□□□□□□a 
□□□□□□□□□□a 
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Ceils:  1024*1024 

Figure  6:  Total  base  memory  of  the  Lattice  Automata 
Machine. 

There  are  eight  Lookup  Tables  (TAB)  and  four  Pro¬ 
grammable  Arithmetic  and  Logic  Unit  (PALU).  In 
each  clock  cycle  we  can  access  the  TAB  or  the  PALU, 
but  not  both.  Each  TAB  sees  the  output  of  the  cor¬ 
responding  BM  (or  I/O  from  other  source  controlled 
by  the  PCU)  for  all  the  18  layers,  giving  the  required 
18  bit  answer  and  4  or  8  bit  color  display.  The  dis¬ 
play  information  is  stored  on  FIFO  (first  in  first  out) 
memory  and  processed  independently  of  the  data  in 
the  BM. 

The  PALUs  split  the  lattice  memory  into  two 
groups.  They  compute  efficiently  products,  cumula¬ 
tive  additions  with  16  bit,  data  copies  and  logic  op¬ 
erations  between  the  two  groups.  If  a  memory  group 
is  a  copy  of  another  memory  group,  we  can  at  least 
double  the  speed  of  operation  and  simultaneously  pre¬ 
serve  the  lookup  tables  for  other  kind  of  local  rules. 

The  PM,  BM,  PSW,  TAB  and  PALU  work  in  par¬ 
allel.  The  main  computer  cycle  is  16.44ms  (60.8  Hz) 
where  all  the  cells  are  updated  (full  configuration)  and 
displayed.  Moreover,  this  basic  architecture  is  expan¬ 
sible  in  the  sense  that  it  is  possible  to  connect  directly 
two  machines,  obtaining  twice  the  performance.  The 
basic  architecture  of  the  LAM  is  presented  in  fig.  7. 

We  now  classify  the  computer  architecture  of  LAM, 
according  to  Flynn,  Feng  and  Erlangen  parallel  archi¬ 
tecture  classification  [6]. 

The  Flynn  classification  is  based  on  instruction  and 
data  streams.  The  multiple  processors  of  LAM  are 
working  on  multiple  data  streams.  Such  kind  of  com¬ 
puters  are  known  as  MIMD  (multiple  instruction  mul¬ 
tiple  data).  This  classification  does  not  contain  any 
information  about  the  type  of  connections  used. 

The  Feng  classification  is  based  on  the  number  of 
bits  that  are  processed  in  parallel  in  a  word,  and  the 
number  of  words  that  are  processed  in  parallel.  This 
classification  does  not  allow  to  distinguish  between 
multiprocessors  and  array  processors  nor  does  it  dis¬ 
tinguish  processing  levels  from  pipeline  structures.  In 
this  case,  LAM  has  144,  1  bit,  parallel  processors: 
Feng(  1,144). 

The  Erlangen  classification  was  developed  mainly 
in  order  to  avoid  the  drawbacks  of  existing  classifi¬ 
cation  schemes.  It  is  assumed  that  the  performance 
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of  the  system  is  mainly  determined  by  the  proces¬ 
sors  and  their  capability  to  transfer  information.  The 
classification  is  based  on  the  distinction  between  three 
processing  levels,  each  one  characterized  by  a  number: 

1)  k:  Number  of  Program  Control  Units  (PCU)  -  Us¬ 
ing  counters,  registers  and  microprogram  devices,  the 
PCU  interprets  a  program  instruction. 

2)  d:  Number  of  Arithmetic  and  Logical  Units  (ALU) 
-  The  ALU  execute  sequences  of  microinstructions  ac¬ 
cording  to  the  interpretation  process  performed  by  the 
PCU. 

3)  w:  Number  of  Elementary  Logic  Units  (ELU)  - 
Each  ALU  contains  several  ELUs,  each  dedicated  to 
process  one  bit.  The  number  of  ELUs  is  commonly 
called  the  word-length  w. 


Figure  7:  Basic  architecture  of  the  Lattice  Automata 
Machine. 

A  computer  configuration  includes  a  number  of 
PCUs  (/c),  each  PCU  controlling  a  certain  number 
of  ALUs  (d).  All  ALUs  perform  the  same  operation 
at  any  given  time.  Different  systems  exhibit  different 
kinds  of  parallelism,  which  are  uniquely  attached  to 
one  of  the  three  levels  A:,  d  and  w. 

If  we  disregard  pipelining,  the  Erlangen  classifica¬ 
tion  will  be  Erlangen  (computer  type)=  (fc,  d,  lu). 

Comparing  computer  performance  of  LAM  with 
other  machines  we  have 


Erlangen(  LAM  )=  (144,8, 18). 
Erlangen(  IBM  701  )=  (1, 1,36). 
Erlangen(  SOLOMON  )=  (1, 1024, 1). 
Erlangen(  ILLIAC  IV  )=  (1,64,64). 
Erlangen(  STARAN  )=  (1,8192, 1). 
Erlangen(  C.mmp  )=  (16, 1, 16), 
Erlangen(  PRIME  )=  (5, 1, 16). 


The  hardware  prototype  of  LAM,  presently  under 
final  assembly  and  test,  is  shown  in  fig,  8. 


Figure  8:  Lattice  Automata  Machine  prototype. 
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1  .  SUMMARY 

The  JTIDS  Joint  Program  Office  (JPO)  has  been  on  the  leading 
edge  of  large  scale  multi-service,  multi-platform,  multi¬ 
mission  JTIDS  network  design  for  several  years. 

Large  scale  network  design  studies  conducted  by  the  JPO  have 
shown  that  if  JTIDS  is  used  efficiently  and  appropriately,  it 
can  meet  expanding  user  and  functional  requirements, 
including  multi-national  operations.  However,  increasing 
reliance  on  JTIDS  for  theater  communications  will  require  a 
continued  effort  to  develop  more  efficient  ways  to  use  it, 

2  .  INTRODUCTION 

The  Tactical  Digital  Information  Link  (TADIL)-Joint  Tactical 
Information  Distribution  System  (JTIDS),  known  as  TADIL  J 
and  also  as  NATO  Link  16,  represents  the  latest  development 
in  the  field  of  TADILs.  The  first  generation  of  JTIDS  hardware 
which  was  fielded  in  the  mid-1980s  consisted  of  what  is 
known  as  the  Class  1  terminal.  This  terminal  is  large  and 
bulky  and,  therefore,  was  integrated  into  only  a  few  large 
command  and  control  (C^)  platforms  such  as  US  and  NATO 
E3s  and  some  key  ground  command  and  control  facilities. 
Since  a  jointly  agreed  upon  digital  message  standard  had  not 
been  developed  by  the  time  the  Class  1  terminals  were 
introduced  to  the  user  community,  an  Interim  JTIDS  Message 
Specification  (IJMS)  was  developed  and  is  still  in  use  today. 
This  initial  Class  1/IJMS  equipment  very  effectively 
supported  coalition  forces  during  Operation  Desert  Storm. 

While  the  Class  1/IJMS  equipment  has  been  in  use,  the 
second  generation  of  JTIDS  hardware  has  been  developed,  was 
approved  for  full  rate  production  in  March  of  this  year,  and 
has  already  been  installed  in  several  operational  systems, 
including  the  USS  Carl  Vinson  carrier  battle  group.  The 
initial  second  generation  hardware  is  represented  by  the 
Class  2  family  of  JTIDS  terminals.  The  Class  2  terminals  are 
smaller,  lighter,  and  more  capable  than  their  predecessors.  In 
addition,  the  JTIDS  user  community  (both  US  and 
international)  have  developed  and  continue  to  refine  the  more 
efficient  and  capable  TADIL  J  (Link  16)  message  standard  for 
use  with  the  new  generation  of  hardware. 

This  combination  of  hardware  and  message  standard 
improvements  has  facilitated  expansion  of  the  planned  JTIDS 
user  base  to  include  most  major  US  C^  platforms  and  a  number 
of  smaller  non-C^  platforms  (e.g.,  fighters).  The 
international  cooperative  development  of  the  Multifunctional 
Information  Distribution  System  (MIDS)  Low  Volume 
Terminal  (LVT).  which  is  even  smaller  than  the  Class  2,  will 
further  support  proliferation  to  the  non-C^  platforms. 

Recent  Department  of  Defense  pronouncement  of  Link  16  as 
the  primary  US  tactical  data  link  should  lead  to  further 


expansion  of  the  Link  16  user  base.  By  the  year  2000,  many 
US  tactical  C^  and  non-C^  platforms  will  be  Link  16  capable. 

3.  PROGRAM  STATUS 

Over  200  Class  2  terminals  have  already  been  bought  under 
low  rate  initial  production  contracts,  of  which  nearly  75% 
have  already  been  delivered.  Current  total  projected  buys  of 
the  Class  2  terminal  are  around  850.  The  total  planned  MIDS 
buys  for  US  platforms  number  around  600  units,  with  the 
allies  planning  to  buy  additional  units. 

4  .  JTIDS  NETWORK  DESIGN  EVOLUTION 
The  Link  16  digital  message  standard  supports  several 
different  functional  categories  of  information  exchange  (e.g., 
surveillance,  engagement  status).  These  categories  are 
known  as  Network  Participation  Groups  (NPGs).  Network 
design  is  the  process  of  allocating  the  finite  capacity  of  the 
JTIDS /Link  16  system  to  a  group  of  JTIDS  equipped  units 
(JUs)  wishing  to  exchange  information  from  the  various 
NPGs  with  one  another. 

JTIDS  uses  a  time  division  multiple  access  (TDMA) 
architecture  with  blocks  of  time  slots  allocated  to  various  JUs 
for  transmission  of  data  on  the  different  NPGs  in  which  they 
wish  to  participate.  The  blocks  of  slots  are  sized  in 
proportion  to  the  expected  capacity  needs  and  are  currently 
statically  assigned.  However,  JTIDS  operates  in  a  line-of- 
sight  (LOS)  frequency  band,  so  relays  are  required  in  order  for 
JUs  beyond  LOS  of  one  another  to  exchange  information. 
Therefore,  network  design  is  not  only  concerned  with 
allocation  of  JTIDS  capacity  for  transmission  of  data,  but  it 
must  also  account  for  capacity  required  for  receipt  and  relay 
transmission  of  data  to  provide  desired  platform 
connectivity. 

4 . 1  Classical  View  of  a  JTIDS  Network 

The  classical  view  of  a  JTIDS  network  is  one  in  which  many 
ground  based  JUs  exchange  data  with  one  another  via  an 
airborne  relay  such  as  an  E3.  Such  an  airborne  relay  can 
provide  connectivity  among  surface  platforms  up  to  500-700 
kilometers  (km)  apart,  and  between  high  flying  airborne  JUs 
up  to  1800  km  apart.  We  refer  to  such  a  network  as  a  single 
(relay)  hop  network.  The  classical  JTIDS  network  structure 
was  envisioned  to  be  of  the  single  hop  variety.  In  this 
classic  network  structure,  it  was  envisioned  that  all  JUs  would 
share  all  of  their  surveillance  data  with  each  other,  providing 
a  common  picture  of  the  tactical  situation  for  all  to  see. 

4.2  First  Wartime  Use,  Large  Scale  Air  Defense 
Network 

Though  the  classic  JTIDS  network  was  single  hop,  the  JTIDS 
system  is  designed  to  support  multiple  relay  hops,  allowing 
the  design  of  networks  with  much  wider  information 
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distribution  potential.  In  fact,  the  first  wartime  use  of  JTIDS 
in  support  of  Operation  Desert  Storm  required  multiple  relay 
hops  to  collect  and  distribute  information  over  the  large 
Saudi-Iraq-Kuwait  border  region.  It  turned  out  that  not  much 
thought  had  been  given  to  the  design  of  such  large  scale 
multi-hop  network  structures.  Consequently,  there  were  no 
existing  network  designs  which  could  be  used,  and  a  special 
multi-hop  network  design  was  created  to  support  the 
operation. 

Though  coalition  forces  ultimately  involved  in  the  Gulf  war 
ranged  from  the  Red  Sea  to  the  Persian  Gulf,  there  were  few 
JTIDS  equipped  platforms  in  theater.  In  fact,  the  Naval  forces 
operating  in  the  Red  Sea  and  the  Persian  Gulf  were  not  JTIDS 
equipped,  so  the  network,  though  large  by  previous  standards, 
only  covered  a  relatively  small  portion  of  the  overall  theater 
geography  and  included  few  direct  JTIDS  participants. 

Despite  using  the  older  Class  1  JTIDS  equipment  with  its 
limitations,  sufficient  capacity  was  available  for  the  network 
design  to  provide  a  fully  shared  surveillance  picture  among  all 
of  the  front  line  air  surveillance  sensors.  This  picture  was 
extended  to  include  a  ground  site  which  had  the  capability  to 
participate  in  the  JTIDS  network  exchanges,  and  to  translate 
the  JTIDS/IJMS  picture  to  TADIL  B  for  distribution  through 
the  theater  TADIL  B  network  to  other  non- JTIDS  participants 
like  the  Joint  Forces  Commander  (JFC)  and  his  Air 
Component  Commander  (JFACC)  in  the  rear.  Unfortunately, 
the  capacity  of  the  existing  TADIL  B  systems  is  much  lower 
than  JTIDS,  so  the  flow  through  the  TADIL  B  structure  was 
much  slower  than  that  experienced  among  the  JTIDS  equipped 
players. 

Despite  the  limitations  in  JTIDS  equipped  platform 
availability,  and  in  the  Class  I’s  capabilities,  the  JTIDS 
network  performed  exceedingly  well,  and  formed  an  effective 
backbone  for  the  JFC’s  Theater  Air  Defense  (TAD)  network 
architecture. 

4.3  Large  Scale  Air  Defense  Network  Studies 
Following  the  Gulf  War,  the  JPO  was  requested  to  answer 
several  questions  relative  to  the  new  JTIDS  Class  2  systems’ 
capabilities.  The  first  was  to  investigate  what  added  benefits 
the  Class  2  equipment  would  have  brought  to  Operation 
Desert  Storm,  assuming  only  that  the  Class  1  terminals  used 
were  replaced  with  the  new  Class  2  terminals.  The  second 
question  was  to  address  what  kind  of  JTIDS  network  might 
have  been  fielded  if  all  of  the  US  forces  involved  in  the  war 
which  were  scheduled  to  receive  the  new  Class  2  terminal  had 
had  it. 

A  network  design  analysis  showed  that  the  answer  to  the  first 
question  was  that  the  new  JTIDS  (i.e..  Class  2  terminal  and 
TADIL  J)  could  have  supported  the  reporting  of  three  to  four 
times  as  many  tracks  per  track  update  cycle  as  the  Desert 
Storm  network  had  (this  figure  is  six  to  eight  times  the  Desert 
Storm  network  capacity  using  one  of  the  Class  2  terminal 
options  which  allows  trading  a  slight  amount  of  jam 
resistance  for  additional  throughput). 

The  answer  to  the  second  question  was  much  more  complex, 
because  it  increased  the  number  of  JUs,  covered  a  much  larger 
geographic  region,  and  required  additional  information 
categories.  To  answer  the  question,  the  JTIDS  JPO  created  an 
expanded  network  covering  the  entire  Southwest  Asia  theater 
from  the  Red  Sea  to  the  Persian  Gulf.  The  network  included 


Navy  assets  in  both  bodies  of  water,  and  JTIDS  equipped  air 
defense  assets  from  all  of  the  other  US  services  across  and 
above  the  land  mass  separating  them. 

4.3.1  The  Common  Picture  Concept 

While  the  actual  Desert  Storm  network  coverage  was  still 
small  enough  to  justify  the  concept  of  a  fully  shared 
surveillance  picture,  the  expanded  Persian  Gulf  to  Red  Sea 
network  was  large  enough  to  bring  this  concept  into 
question.  For  example,  in  designing  such  a  large  network, 
one  must  ask  whether  it  is  necessary  (or  even  useful)  for  Navy 
units  in  the  Persian  Gulf  to  have  a  near-real-time  picture  of  the 
tactical  situation  in  the  Red  Sea.  Many  such  questions  must 
be  answered  in  the  very  large  scale  represented  by  the  Persian 
Gulf  to  Red  Sea  network.  Certainly  for  some  players  in  such  a 
large  theater  (e.g.,  the  JFC  or  JFACC),  a  view  of  the  tactical 
picture  across  the  whole  theater  would  be  very  desirable,  but 
the  players  with  such  broad  information  needs  are  exceptions 
rather  than  the  rule. 

4.3.2  Finite  Resources 

If  communications,  information  processing,  and  information 
display  capacities  were  unlimited,  one  might  take  the  view 
that  all  available  tactical  information  in  theater  should  be 
distributed  to  everyone,  permitting  each  participant  to 
display  any  data  at  any  time.  However,  even  diough  the  new 
JTIDS  offers  network  communications  capacities  many  times 
that  of  existing  TADILs,  processing  power  is  orders  of 
magnitude  higher  than  it  was  only  a  few  years  ago,  and 
display  technology  has  vastly  improved,  all  of  these 
resources  are  finite.  Consequently,  as  network  size  and 
numbers  of  participants  grow,  there  is  a  point  at  which  the 
limits  of  these  resources  begin  to  come  into  play. 

4.3.3  Capacity  and  Connectivity  Tradeoffs 

The  result  is  that,  as  network  size  and  participation  grow, 
there  is  a  point  at  which  tradeoffs  of  these  finite  resources 
must  begin  to  be  made.  For  example,  the  new  JTIDS  provides 
ample  capacity  for  the  battle  group  in  the  Persian  Gulf  to 
implement  all  of  the  local  internal  battle  group  information 
exchanges  they  deem  necessary,  but  if  there  are  additional 
JTIDS  equipped  sensors  set  up  ashore  that  could  provide  them 
with  some  advanced  warning  of  approaching  threats  from  the 
west,  it  may  be  useful  to  monitor  that  data  via  JTIDS  as  well. 
If  this  could  be  implemented  without  sacrificing  any  local 
battle  group  information  exchange  capabilities,  all  is  well 
and  good.  But  then  if  additional  sensors  are  set  up  further  to 
the  west,  maybe  it  would  be  desirable  to  monitor  them  as 
well.  Eventually,  it  may  be  that  monitoring  more  and  more 
distant  data  uses  up  so  much  capacity  that  it  causes  the  battle 
group  to  have  to  give  up  some  of  its  desired  local  information 
transactions  (e.g.,  a  local  JTIDS  voice  channel). 

4.3.4  The  Cost  of  JTIDS  Relay 

In  addition,  getting  data  routed  to  distant  parts  of  a  large 
network  usually  involves  the  use  of  many  relays,  and  the 
relays  have  to  use  double  the  capacity  for  information  they 
are  required  to  relay.  This  is  because  the  ultimate  recipients  of 
the  data  only  need  to  commit  enough  capacity  to  receive  the 
data,  while  the  intervening  relays  must  not  only  use  capacity 
to  receive  the  data,  they  must  also  allocate  the  same  amount 
of  capacity  to  relay  it. 

Fortunately,  the  new  JTIDS  was  designed  with  many  capacity 
enhancing  features  that  allow  it  to  accommodate  network 
structures  many  times  larger  (geographically  and  in  numbers 
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of  participants)  than  Class  1  terminal  and  IJMS  networks 
before  such  tradeoffs  are  required.  However,  the  expanded 
Persian  Gulf  to  Red  Sea  network  is  large  enough  to  require 
consideration  of  connectivity  and  capacity  tradeoffs. 
Operationally  it  becomes  a  matter  of  trading  off  local 
capabilities  to  support  wider  distribution  of  data.  This  then 
translates  into  having  to  make  judgments  as  to  whether 
greater  benefit  is  derived  from  the  wider  distribution  of  data 
versus  the  potential  loss  of  local  capabilities. 

Connectivity  versus  capacity  tradeoffs  are  required  in  large 
scale  networks.  Trades  were  made  in  the  expanded  Persian 
Gulf  to  Red  Sea  air  defense  network  by  making  selected 
connectivity  reductions  to  improve  local  tactical  capabilities 
(e.g.,  fighters  don’t  have  to  use  some  of  their  capacity  to 
listen  to  distant  air  tracks  (e.g.,  over  500  miles  away),  so 
they  are  able  to  support  a  higher  local  fighter-to-fighter 
target  exchange  rate).  The  reductions  attempted  to  recognize 
special  roles  and  missions  of  certain  key  players  in  the 
network  like  the  JFC  and  JFACC  and  to  continue  to  provide 
them  the  entire  ‘big  picture.’  To  maximize  other  (e.g., 
fighter)  tactical  platform  local  data  exchange  capabilities 
(and,  therefore,  hopefully  mission  effectiveness),  they  were 
scheduled  to  monitor  their  local  area  surveillance  picture,  and 
only  those  other  sensors  within  several  hundred  miles  around, 
but  not  all  theater  sensors. 

4.4  Addition  of  Theater  Missile  Defense 
While  contemplating  the  requirements  of  a  communications 
system  to  support  Theater  Missile  Defense  (TMD),  the 
Ballistic  Missile  Defense  Organization  (BMDO)  took  note  of 
the  large  scale  network  design  work  being  done  in  the  JTIDS 
and  air  defense  communities.  TMD  has  a  theater-wide 
communication  requirement,  and  JTIDS  was  showing  its 
potential  for  providing  theater-wide  communications 
capabilities.  One  particularly  attractive  feature  of  JTIDS  was 
that  it  was  already  planned  to  be  installed  in  many  of  the 
platforms  that  would  be  involved  in  TMD. 

To  evaluate  the  feasibility  of  using  JTIDS  to  concurrently 
support  both  TAD  and  TMD,  the  BMDO  requested  that  the  JPO 
perform  a  JTIDS  TMD  Utility  Analysis,  using  the  network 
design  approach  which  had  been  used  in  the  evolving  air 
defense  network  expansion  studies.  The  plan  was  to  use  the 
expanded  Persian  Gulf  network,  and  another  large  scale  air 
defense  network  design  based  on  a  Northeast  Asia  (NEA) 
scenario  as  baseline  air  defense  networks.  The  services  would 
then  define  additional  platforms  and  communications  required 
to  be  added  to  those  networks  to  support  TMD.  The  BMDO 
was  particularly  concerned  with  the  potential  impact  of  the 
added  TMD  communications  on  the  air  defense  capabilities  of 
the  baseline  networks. 

The  resulting  TAD/TMD  network  designs  and  loading 
analysis  results  convinced  the  services  and  the  BMDO  that  if 
TMD  communications  requirements  were  integrated 
efficiently,  then  JTIDS  could  absorb  the  added  TMD  message 
traffic  with  minimal  impact  on  air  defense.  Based  on  these 
results  the  BMDO  endorsed  JTIDS  as  the  primary  terrestrial 
data  link  in  support  of  TMD.  Since  that  time,  the  TMD 
community  has  been  busy  developing  new  Link  16/TADIL  J 
messages  to  actually  implement  the  BMDO  decision. 


4.5  Emerging  Large  Scale  Network  Design 
Issues 

As  geographic  coverage  expands,  the  network  capacity 
available  for  sharing  of  sensor  tracks  among  widely  dispersed 
groups  of  sensors  and  weapons  systems  (which  we  call  the 
joint  Wide  Area  Surveillance  (WAS)  net  structure)  has  to  be 
subdivided  among  the  different  geographic  areas  (which  we 
call  ‘zones’).  For  networks  with  several  zones  (e.g,,  the  two 
air  defense  baseline  networks),  the  WAS  capacity  allocations 
to  the  zones  appear  to  be  adequate  to  handle  a  concurrent  air 
and  missile  threat  at  the  levels  specified  in  the  scenarios 
studied.  However,  if  the  WAS  participants  within  a  zone 
caimot  dynamically  share  the  zone  capacity,  the  zone 
allocation  has  to  be  further  subdivided  among  the  zone 
members.  If  there  are  large  numbers  of  members  in  a  zone  aU 
desiring  access  to  the  zone’s  WAS  capacity,  without  dynamic 
capacity  sharing  capabilities,  the  result  could  be  marginal  or 
inadequate  individual  allocations. 

4.5.1  Dynamic  Capacity  Sharing  Needed 

As  concurrent  TAD/TMD  networks  grow  in  size  and 
membership,  the  need  for  dynamic  capacity  allocation  grows. 
Fortunately,  the  US  and  the  UK  recognized  the  approaching 
need  for  dynamic  capacity  sharing  some  years  ago,  and 
developed  a  dynamic  capacity  sharing  scheme  called  Time 
Slot  Reallocation  (TSR).  Unfortunately,  few  planned  JTIDS 
platforms  have  yet  committed  to  the  use  of  TSR,  so  large 
scale  network  designs  must  still  statically  subdivide  available 
capacity  so  many  ways  that  optimum  theater  wide  mission 
effectiveness  cannot  be  achieved.  Continuing  network 
design  studies  and  analyses  are  heightening  awareness  of  the 
need  for  dynamic  capacity  sharing,  and  all  of  the  US  services 
as  well  as  the  BMIX)  now  officially  recognize  the  benefits  of 
TSR  and  are  pursuing  investigation  into  its  more  widespread 
implementation. 

4.5.2  Non-JTIDS  Range  Extension  Needed 

The  large  scale  concurrent  TAD/TMD  communications  studies 
that  have  been  done  to  date  assume  that  JTIDS  will  be  used  to 
support  long  haul  communications  within  the  theater. 
However,  as  network  size  and  participant  numbers  increase, 
the  increasing  long  haul  relay  burden  can  take  away  capacity  a 
platform  could  have  used  to  enhance  its  own  local  tactical 
capabilities  and  mission  effectiveness.  Though  it  possesses 
capabilities  which  allow  it  to  handle  many  theater  long  haul 
communications  requirements,  JTIDS  was  never  intended  to 
support  such  long  haul  communications  on  a  large  scale. 

Long  haul  non- JTIDS  communications  alternatives  which  can 
mesh  well  with  JTIDS  are  needed  (the  Desert  Storm  network 
architecture  used  mismatched  TADIL  B). 

5  .  CONCLUSIONS 

JTIDS  networks  have  been  designed  which  demonstrate 
coverage  in  both  area  and  mission,  well  beyond  that 
originally  conceived  of  for  the  data  link.  However,  JTIDS 
capacity  for  such  large  scale  concurrent  TAD/TMD  networks 
is  being  strained.  Stress  on  JTIDS  networks  due  to  continued 
expansion  of  JTIDS  users  and  functions  can  be  mitigated  with 
improvements  in  efficiency  of  use.  Two  methods  for 
improving  efficiency  were  discussed:  1)  reduction  of  the 
long  haul  relay  burden  from  JTIDS  units  through  development 
and  use  of  non- JTIDS  TADIL  J  communication,  and  2)  the 
implementation  of  dynamic  capacity  sharing  capabilities 
such  as  TSR  in  key  JTIDS  platforms. 
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These  conclusions  are  based  on  large  scale  networks  for 
which  we  have  assumed  unrestricted  JTIDS  operation.  Small 
scale  concurrent  TAD/TMD  contingency  operations  with 


peacetime  JTIDS  frequency  allocation  restrictions  may  be 
required.  The  viability  of  such  networks  also  needs  to  be 
investigated. 


This  information  is  fumisheh  on  the  condition  that  it  wiU  not  be  released  to  another  nauon  tmthout  ^cific  auAonty  of  the 

United  States,  that  it  wiU  be  used  for  military  purposes  only,  that  individual  or  corporate  nghts  onginating  m  ^e  infomation,  whether  patented  or 
respected,  that  the  recipient  will  report  promptly  to  the  United  States  any  known  or  suspected  compromise,  and  that  the  informauon  will  be  provided  the  same 
degree  of  security  afforded  it  by  the  D^artment  of  Defense  of  the  United  States. 
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1 .  Summary 

Improved  communications  technology  often 
leads  to  improved  command  and  control 
capabilities  and,  in  some  cases,  to  new  modes 
of  operation.  Asynchronous  transfer  mode 
(ATM)  communications  has  the  potential  to  be 
the  kind  of  technology  that  will  permit 
significant  changes  in  both  the  command  and 
control  architecture  and  physical  relationships 
of  component  and  support  elements.  This 
paper  will  describe  ATM  technology  and  its 
application,  possible  impact,  and  current 
status  with  respect  to  military  situations. 

2.  Introduction 

Effectively  fighting  a  modern  tactical  war,  and 
efficiently  using  resources,  increasingly 
depends  on  the  skilled  processing  and  dissem¬ 
ination  of  data,  including  imagery.  Moreover, 
making  the  right  tactical  decisions  requires  the 
collaborative  efforts  of  commanders  and  their 
staffs  across  components  and  echelons.  This 
mutual  collaboration  requires  sharing  data  and 
using  video  teleconferences  to  facilitate  dis¬ 
cussions,  and  the  communications  infras¬ 
tructure  must  support  these  activities. 

The  existing  tactical  communications 
resources  are  often  among  the  most  difficult  to 
use  efficiently  because  of  the  architectural 
constraints  imposed  by  switched  circuits  and 
the  hardware  and  software  which  control 
them.  The  recent  introduction  of  a  limited 
number  of  packet  data  networks  has  provided 
increased  flexibility  in  the  use  of  bandwidth 
insofar  as  any  user  is  allowed  to  use  as  much 
bandwidth  as  he  needs  as  long  as  it  is  avail¬ 
able.  However,  even  the  performance  of  these 
packet  systems,  which  are  most  efficient  for 
asynchronous  message  traffic  and  datafile 
transfers,  begins  to  degrade  as  the  aggregate 
bandwidth  demand  exceeds  some  nominal 


threshold;  and  switched  circuits  remain 
necessary  for  those  purposes,  such  as  voice 
and  video,  that  require  isochronous  operation 
with  low  latency  and  stable  time  references. 

ATM  technology  holds  the  promise  of 
combining  the  benefits  of  both  packet  and 
switched  circuit  systems,  thereby  yielding  a 
more  integrated,  efficient,  and  effective  way 
to  both  transfer  data  and  to  provide  voice  and 
video  service.  It  will  permit  a  different,  more 
flexible  architecture,  and  it  should  also  allow 
more  coordination  between  geographically 
dispersed  elements. 

3 .  ATM  Overview  and  Capabilities 

ATM  is  an  emerging  communications 
technology  that  is  designed  to  internetwork 
voice,  video,  and  data  applications  over  a 
common  physical  link.  It  is  a  connection 
oriented  technology  based  on  the  concept  of 
segmenting  all  digital  data  flowing  through  the 
network  into  short,  fixed  length  cells  that  can 
be  processed  rapidly  within  ATM  switches 
and  network  interfaces.  This  technology  also 
permits  the  interleaving  of  cells  from  multiple 
users  and  multiple  application  types  on  the 
same  physical  media  to  allow  both  for 
efficient  use  of  the  network  bandwidth  and  for 
time- varying  bandwidth  allocations,  com¬ 
monly  referred  to  as  bandwidth-on-demand. 

ATM  Cell  Structure.  All  digital  telephony 
(voice),  video,  and  data  sent  over  ATM-based 
networks  is  segmented  into  53  byte  fixed 
length  cells  which  have  48  byte  payloads.  The 
same  basic  53  byte  cell  structure  is  used 
regardless  of  whether  the  network  is  a  local 
area  network  (LAN),  metropolitan  area 
network  (MAN),  or  a  wide-area-network 
(WAN).  Consequently,  gateways  are  never 
required  to  translate  protocols  with  ATM 
technology. 


Paper  presented  at  the  AGARD  MSP  3rd  Symposium  on  "'Tactical  Aerospace  Ol  in  Coming  Years**, 
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Figure  1  shows  the  ATM  cell  structure  for 
cells  at  the  user  network  interface  (UNI).  The 
fields  in  the  diagram  are: 

1 .  GFC  (generic  flow  control)  regulates  the 
flow  of  cells  during  periods  of 
congestion. 

2.  VPI  (virtual  path  indicator)  provides  a 
logical  grouping  of  virtual  circuits  and 
identifies  a  node-to-node  path  between  the 
source  and  destination  ports. 

3 .  VCI  (virtual  channel  indicator)  identifies 
cells  within  a  data  stream. 

4 .  PTI  (payload  type  indicator)  distinguishes 
payload  data  as  either  user  information  or 
network  configuration  information. 

5 .  CLP  (cell  loss  priority)  determines  which 
cells  may  be  dropped  when  a  switch 
encounters  congestion. 

6 .  HEC  (header  error  correction)  detects 
errors  in  the  header  (only)  and  corrects 
single  bit  errors.  Cells  are  dropped  if 
header  errors  cannot  be  corrected. 

For  ATM  cells  being  transmitted  between 
switches,  at  the  network-network  interface 
(NNI),  the  GFC  field  is  subsumed  into  the 
VPI  to  allow  sixteen  times  more  VPIs. 

The  ATM  Protocol  Architecture.  The  ATM 
protocol  architecture  has  two  separate  protocol 
layers,  the  ATM  layer  and  the  ATM  adaptation 
layer  (AAL),  that  closely  approximate  the 
functionality  of  the  link  and  the  network 
layers,  respectively,  of  the  seven  layer  OSI 
Reference  Model.  The  ATM  protocol  layers 
include  some  of  the  characteristics  of  other 
OSI  Reference  Model  layers,  functioning  as 
the  data  link,  network,  and  transport  layer 
protocols  because  they  provide  error 
detection,  routing,  and  (end-to-end) 
permanent  and  switched  virtual  circuits. 

Figure  2  illustrates  a  mapping  of  the  ATM 
protocols  to  the  OSI  Reference  Model.  The 
ATM  Protocol  Architecture  shows  the  ATM 
layer  and  the  AAL  replacing  the  data  link  and 
network  layers. 

An  application  can  access  the  AAL  directly, 
consequently,  the  network,  transport, 
session,  and  presentation  layers  are  optional 


and  are  represented  with  different  shading. 
However,  some  applications  may  utilize 
protocols  implement  the  layers  that  exist 
above  the  AAL.  For  instance,  existing 
Transmission  Control  Protocol/Internet 
Protocol  (TCP/IP)  applications  can  run  over 
ATM-based  networks  that  use  the  entire 
protocol  stack.  Below  the  network  layer, 
device  drivers  for  ATM  network  interface 
cards  direct  the  variable  length  TCP/IP 
packets  to  the  AAL,  where  they  are  segmented 
into  48  byte  cell  payloads,  and  sent  through 
the  ATM  layer  to  the  physical  layer.  When 
receiving  ATM  cells,  the  AAL  reassembles  the 
TCP/IP  packets  from  one  or  more  cells  before 
the  packet  proceeds  up  through  the  IP  stack. 

ATM  Technology.  ATM  technology  is 
connection  oriented,  where  network  connec¬ 
tions  are  simply  logical  information  pipes  of 
variable  capacity  with  characteristics  specified 
by  the  user  application.  It  is  assumed  that  cells 
arrive  in  the  order  sent.  Isochronous  constant 
bit  rate  (CBR)  applications  such  as  telephony 
or  video  have  stringent  requirements  for  end- 
to-end  cell  transmission  delays  and  cell 
interarrival  variability  or  jitter,  and  require 
assurances  that  adequate  bandwidth  will  be 
available.  To  support  isochronous  data  traffic 
in  an  asynchronous  data  stream,  users  can 
reserve  a  predetermined  amount  of  bandwidth 
for  an  application.  Some  isochronous  appli¬ 
cations,  such  as  variable  bit  rate  (VBR)  voice 
or  adaptive  compressed  frame  video  images 
using  Joint  Photographic  Experts  Group 
(JPEG)  compression  or  Motion  Pictures 
Experts  Group  (MPEG)  compression, 
generate  data  at  a  VBR,  but  the  isochronous 
nature  of  the  data  requires  that  some  fraction 
of  the  overall  maximum  bandwidth  be 
reserved.  Unused  bandwidth  is  allocated  to 
other  network  applications  that  do  not  reserve 
bandwidth  because  they  require  only  best- 
effort  service,  or  unused  bandwidth  can  be 
allocated  to  other  VBR  network  connections 
that,  for  a  short  period,  require  more 
bandwidth  than  had  been  reserved. 

ATM  cell  streams  are  uniquely  identified  by 
VPI/VCI  tuples  so  that  several  physical 
signals  can  be  placed  sequentially  on  a  single 
physical  media.  Each  cell  carries  an  identifier, 
so  it  can  be  placed  on  the  physical  media 
asynchronously  and  any  number  of  cells  can 
be  placed  on  the  media  as  long  as  bandwidth 
reservations  for  the  connection  and  physical 
limitations  on  bandwidth  are  observed.  While 
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there  is  only  a  single  data  stream  on  the 
physical  layer,  users  can  think  of  dividing  that 
stream  into  (virtual)  bundles  of  (virtual) 
wires,  an  analog  from  the  era  when  individual 
connections  were  carried  over  copper  wire  on 
a  physical  circuit.  Because  the  only  bandwidth 
limitations  on  the  virtual  wire  are  imposed 
when  reserving  bandwidth,  any  ATM  cell 
stream  could  conceptually  consume  all 
available  bandwidth  on  a  physical  link  at  any 
instant. 

When  there  are  several  ATM  cell  streams 
being  multiplexed  over  a  single  physical  link, 
allocation  of  the  bandwidth  is  performed 
statistically — according  to  guidelines  defined 
as  the  user  applications  set  up  connections. 
Even  with  multiple  user  cell  streams  statis¬ 
tically  multiplexed  into  a  single  transmitted 
data  stream,  each  user  cell  stream  must 
maintain  its  fundamental  characteristics.  CBR 
traffic  must  arrive  with  limits  on  the  variability 
of  the  latency,  as  defined  by  the  user.  Cell 
latency  is  defined  by  propagation  distance  and 
processing  delays  through  the  communi¬ 
cations  network — factors  that  cannot  be 
avoided.  As  long  as  delays  have  limited 
variability,  or  jitter,  isochronous  CBR  signals 
can  be  transported  over  ATM  networks  with 
no  degradation  induced  by  the  statistical 
multiplexing. 

Statistical  multiplexing  can  be  contrasted  with 
time-division  multiplexing  (TDM),  where 
bandwidth  is  divided  into  discrete  time  slots 
that  are  assigned  to  a  user  for  the  duration  of  a 
call.  Statistical  multiplexing  uses  only  the 
bandwidth  required  at  any  instant  and  ATM 
protocols  permit  users  to  obtain  extra  band¬ 
width  as  required  for  bursts  of  data;  however, 
the  potential  for  problems  arise  because  of  the 
possibility  that  jitter  or  variability  could  occur 
in  the  critical  timing  for  isocronous  data 
streams.  On  the  other  hand,  TDM  has  typi¬ 
cally  been  used  to  allocate  bandwidth  to 
various  physical  circuits  simultaneously  in 
previous  generations  of  circuit  switched  com¬ 
munications  equipment.  For  time-division 
multiplexed  transmissions,  it  is  simple  to 
maintain  constant  latency  by  assigning  ade¬ 
quate  time-division  slots  to  handle  maximum 
anticipated  bandwidth  requirements.  How¬ 
ever,  the  link  receives  all  bandwidth  whether 
or  not  information  is  being  transmitted  in  an 
assigned  time  slot,  and  there  is  no  way  to 
obtain  additional  bandwidth  if  there  is  a  short¬ 
term  requirement  for  sending  bursts  of  data. 


An  important  feature  with  ATM  technology  is 
the  UNI  and  the  NNI  protocols.  The  ATM 
UNI/NNI  protocols  will  provide  fully  auto¬ 
mated  network  operations.  User  applications 
will  request  switched  virtual  circuits  (SVCs) 
and  will  reserve  required  bandwidth  automat¬ 
ically  when  connections  are  established.  The 
ATM  UNI/NNI  protocol  will  also  provide 
adequate  intelligence  within  ATM  switches  to 
reroute  network  connections  affected  by  link 
failures  and  to  process  requests  for  additional 
bandwidth  on  a  connection.  Implementations 
of  the  UNI/NNI  conforming  to  the  standards 
from  CCITT  and  the  ATM  Forum,  Q2931  and 
UNI  V3.0,  have  begun  to  appear  in  produc¬ 
tion  switches,  and  the  standards-based  UNI/ 
NNIs  are  replacing  propriety  UNI/NNI  imple¬ 
mentations  that  have  operated  with  great 
success  on  single- vendor  networks  for  several 
years.  Interoperable  SVCs  and  a  fully  auto¬ 
mated  UNI/NNI  will  foster  wide  acceptance 
of  ATM  technology  in  both  the  military  and 
the  civilian  community.  Interoperable,  fully 
automated  SVCs  combined  with  a  capable 
network  management  system,  should  reduce 
staffing  requirements  for  deployed  ATM- 
based  communications  networks. 

Priority  is  significant  for  military  applications 
of  ATM,  because  the  requirement  exists  to 
replicate  the  concept  of  flash  message  traffic, 
a  feature  that  cannot  be  adequately  imple¬ 
mented  with  only  the  concept  of  reserved 
bandwidth.  CLP  is  a  single  bit  used  to  denote 
two  classes  of  priority  that  determine  which 
cells  should  be  dropped  when  the  switch 
encounters  congestion.  Development  efforts  at 
Rome  Laboratory  have  demonstrated  that  it  is 
possible  to  implement  multiple  levels  of 
priority  for  a  virtual  circuit  at  the  time  the 
connection  is  established,  but  that  feature  is 
not  currently  part  of  the  ATM  specifications. 


4 .  Tactical  Military  Applications  and 
Implications 

Current  operations.  Current  US  doctrine  is 
predicated  on  a  two-tier  architecture  for  joint 
task  force  operations  needed  to  cope  with 
crisis  events  (Figure  3).  This  architecture  is 
based  on  having  a  theater  commander-in-chief 
(CINC)  and  his  staff  in  a  garrison  location 
and  the  Joint  Task  Force  Commander  (CJTF), 
his  staff,  and  the  component  elements 
deployed  to  a  position  in  the  combat  area. 
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Anchor  desks  with  access  to  large  amounts  of 
reference  data  and  processed  information 
regarding  weather,  logistics,  intelligence,  and 
other  support  functions  will  most  likely  be 
collocated  with  the  CINC. 

Presently,  the  deployed  forces  communicate 
with  each  other,  and  with  the  CINC,  over 
dedicated  circuits,  usually  either  satellite, 
troposcatter,  or  HF  radio  (or  public  switched 
telephone  networks  if  the  infrastructure 
exists),  but  cooperative  sharing  of  resources 
between  users  is  often  not  practical  because, 
for  instance,  while  the  weather  and  logistics 
channels  are  generally  not  only  functionally 
separate,  they  are  also  usually  physically 
distinct.  Another  example  would  be  a  video¬ 
teleconference  circuit  link  between  the  CINC 
and  CJTF  which  could  not  be  shared  with  one 
of  the  force  component  commanders  or  be 
used  for  the  exchange  of  imagery  without 
changing  the  multiplexing  plan.  This  diversity 
of  applications  and  the  lack  of  flexibility  in 
using  communications  assets  can  result  in  the 
inefficient  use  of  scarce  resources. 

The  packet  data  networks  are  a  different  issue. 
Currently  being  put  into  tactical  situations  on  a 
large  scale,  they  allow  several  users  to  share 
common  transmission  resources  which 
connect  to  other  networks;  new  systems  and 
standards  improve  interoperability  and  make 
messaging,  electronic  mail,  and  electronic  file 
transfers  simpler  and  more  effective.  Specifi¬ 
cally,  TCP/IP  networks  and  emerging  mes¬ 
sage  standards  are  interoperable  and  utilize 
commercial  hardware  and  software  implemen¬ 
tations — the  major  issue  is  one  of  system 
acquisition  and  compatibility  of  applications. 
And  these  systems  are  limited  in  their  ability 
to  accommodate  isochronous  traffic 
effectively  (notably  voice  and  video). 

Future  possibilities.  The  information  from  the 
anchor  desks  is  to  be  disseminated  to  the  task 
force  either  by  “smart  push”  or  “warrior  pull” 
of  the  necessary  data  and  imagery,  and  there 
is  an  increasing  desire  to  have  cooperation 
between  military  service  components  and 
between  the  CJTF  and  the  CINC  in  the  collab¬ 
orative  planning  of  operations.  In  practice, 
given  the  trends  for  tactical  communications, 
the  two-tier  concept  for  a  joint  task  force  leads 
to  the  possibility  of  having  parts  of  tactical 
units,  such  as  an  air  operations  center  or  a 
corps  headquarters,  interconnected  by  wide¬ 
band  fiber  optic  cable  to  create  “crystal 


islands”  at  forward  locations;  those  islands 
themselves  may  be  connected  by  constrained 
narrower  bandwidth  channels.  This  will 
permit  units  to  move  large  amounts  of  data 
within  themselves  while  passing  smaller 
amounts  to  and  from  external  sources.  This 
results  in  the  need  for  seamless  communi¬ 
cations  between  echelons  and  between  forces 
across  echelons  as  well  as  for  common 
software  applications  on  the  workstations. 

The  capabilities  of  an  ATM-based  system 
facilitate  this  joint  tactical  force  structure  by 
permitting  distributed  collaborative  planning 
among  and  between  the  JTF  and  CINC 
elements  through  the  use  of  video  teleconfer¬ 
encing,  shared  graphics,  and  shared 
databases.  All  units  will  be  able  to  see  a 
common  tactical  picture  and  respond  to  a 
common  threat.  This  capability  also  suggests 
that  not  all  support  functions  will  have  to  be 
deployed  to  the  battle  area,  that  split-base 
concepts  can  be  employed,  and  that  resources 
can  be  used  more  efficiently.  Some  of  the 
support  personnel  who  might  normally  be 
deployed,  and  their  computers,  can  be  utilized 
at  a  distance — in  effect,  trading  bandwidth  for 
people  on  site.  This  virtual  deployment  would 
save  money  and  time  by  reducing  airlift 
requirements,  reducing  logistics  in-theater, 
reducing  force  size,  and  reducing  the  planning 
cycle. 

ATM  permits  these  gains  because  the  under¬ 
lying  protocols  make  more  efficient  use  of  the 
communications  resources  than  is  currently 
possible.  The  use  of  common  communi¬ 
cations  resources  in  an  ATM  network  allows 
users  to  request  bandwidth-on-demand  rather 
than  have  the  fixed  bandwidth  assignment  of 
the  traditional  stove-pipe  systems;  that  means 
the  detailed  need-line  analysis  between 
specific  points  prior  to  deployment  may  be 
replaced  by  an  analysis  of  aggregate  band¬ 
width  required.  In  addition,  there  is  no  longer 
a  requirement  for  the  reallocation  of  specific 
links  as  users  come  and  go  in  the  network. 
Finally,  ATM  makes  common/interoperable 
command  and  control  applications  more 
valuable  because  the  underlying  communi¬ 
cations  are  compatible. 
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5.  Issues 

All  of  the  commercial  ATM  Broadband 
Integrated  Services  Data  Network  (BISDN) 
industry  is  based  on  compliance  with  accepted 
CCITT  international  standards  as  interpreted 
by  the  ATM  Forum,  a  group  of  corporations 
and  organizations  involved  in  developing  and 
marketing  ATM  products  and  services.  As  a 
result  of  this  cooperation,  there  are  several 
commercial  vendors  of  ATM  switches  and 
interface  cards,  and  commercial  ATM  service 
is  about  to  emerge  in  the  US  and  Europe. 

This  has  facilitated  the  acceptance  of  ATM  by 
the  US  military;  the  technology  has  already 
been  demonstrated  in  exercises  (Joint  Warrior 
Interoperability  Demonstration  and  Agile 
Provider).  ATM  technology  has  been  included 
in  testbeds  (Joint  Advanced  Development 
Environment)  and  there  has  been  tentative  use 
in  commercial  service  (MCI,  NYNET,  Sprint, 
Wiltel,  Bell  Atlantic,  etc.). 

Notwithstanding  these  achievements 
grounded  on  commercial  systems  and 
equipment,  there  are  several  tactical  military- 
specific  issues  yet  to  be  resolved  before  ATM 
service  can  be  reliably  extended  to  the  theater; 
several  of  these  considerations  are  discussed 
below. 

ATM  standards  must  be  established  for  oper¬ 
ation  over  disadvantaged  tactical  channels, 
including  the  probable  need  for  military-spe¬ 
cific  forward  error  correction  to  reduce  the 
effective  error  rate  on  noisy  tactical  channels. 
ATM  was  originally  designed  for  use  over 
optical  fiber,  a  low-error-rate  wideband 
transmission  medium,  but  tactical  communi¬ 
cations  are  typically  narrow-band  high-error- 
rate  channels  which  will  affect  the  data  pay- 
load  more  than  the  cell  headers  which  have 
forward  error  correction  coding  required  by 
the  ATM  standards.  Since  data  payload  errors 
will  cause  packet  errors  (if  the  transport  layer 
protocol  is  the  current  military  standard 
TCP/IP)  which  in  turn  will  cause  retrans¬ 
mission  of  packets,  this  problem  has  to  be 
solved  before  the  retransmission  effects 
further  reduce  the  amount  of  usable  data  on 
the  link.  Furthermore,  ATM  is  not  a  reliable 
protocol  like  X.25  which  guarantees  delivery 
of  the  data  and  cells  can  be  lost  or  corrupted 
without  the  source  knowing  about  it.  Some 
accommodations  will  have  to  be  inade  in  order 
to  account  for  these  effects  and  Rome 


Laboratory  is  pursuing  alternative  solutions  to 
this  problem. 

There  is  also  a  requirement  for  a  wideband, 
reliable  communications  infrastructure 
connecting  tactical  crystal  islands.  If  the 
workstations  at  an  air  operations  center  are 
connected  with  fiber  optic  cables  and  are, 
therefore,  capable  of  using  ATM  protocols  for 
internal  operations,  it  is  important  for  those 
workstations  to  also  be  interoperable  with 
workstations  at  the  CINC  and  at  wing  oper¬ 
ations  centers  at  remote  air  bases.  That  implies 
the  need  for  ATM  connectivity  over  either 
satellite  or  troposcatter  links. 

In  addition,  since  tactical  units  imply  mobility, 
there  is  a  requirement  for  a  network  manage¬ 
ment  scheme  which  permits  units  to  move 
from  one  hub/switch  to  another  and  which  is 
not  subject  to  compromise  from  external 
elements.  To  the  degree  that  an  air  operations 
center  will  probably  not  move  once  it  is  in 
place  (or  at  least  it  will  not  move  often),  it 
mimics  normal  commercial  installations.  But 
that  relative  stability  isn’t  true  of  all  Air  Force 
units  and  it  certainly  isn’t  true  for  Army  units, 
so  the  switch  controllers  and  network  man¬ 
agers  have  to  be  able  to  accommodate  this 
volatility. 

Similarly,  commercial  ATM  networks  are 
designed  on  the  assumption  that,  given  the 
bandwidth  of  the  transmission  media,  there  is 
no  need  for  priority  and  precedence  features  in 
the  protocols.  Military  networks,  however, 
have  historically  had  priority  and  precedence 
features,  and  the  need  for  those  features 
remains  in  a  military  ATM  network  with 
disadvantaged  links  that  can  only  carry  a 
limited  amount  of  traffic  between  high-priority 
locations. 

Security  is  another  issue  which  has  histori¬ 
cally  been  significant  in  a  military  environ¬ 
ment  and  that  has  recently  been  recognized  as 
a  problem  in  commercial  networks  as  indus¬ 
trial  organizations  and  financial  institutions 
move  large  volumes  of  sensitive  information 
in  public  networks.  It  will  become  even  more 
important  as  the  proprietary  military  networks 
fade  and  military  information  is  transported 
over  public  networks.  This  implies  a  need  for 
high-speed  cell  payload  encryption  devices,  as 
opposed  to  bulk  encryption,  as  well  as  assur¬ 
ance  that  the  management  information  base 
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and  the  network  management  software  are  not 
exposed  to  possible  exploitation. 

6.  Status 

Some  of  the  problems  described  above  are 
being  addressed  in  several  efforts.  First,  the 
Air  Force  is  completing  the  development  of  a 
concept  model  of  an  ATM-based  tactical 
switch  that  will  enable  a  wide  variety  of 
experiments  on  these  issues.  Called  the 
Secure,  Survivable  Communications 
Network,  or  SSCN,  it  was  built  by  GTE 
Corporation  based  upon  their  commercial 
product.  Several  features  are  provided  by 
SSCN  which  were  driven  by  the  perceived 
military  environment.  These  include;  a 
modular  interface  to  low  rate  channels  down 
to  64  Kbps,  interface  to  the  TRI-TAC  trunk 
rates,  accountability  of  cells  received  with 
corrupted  headers  (for  security  reasons),  and 
multiple  levels  of  priority  with  preemption. 

To  enable  a  broader  experimental  program, 
Rome  Laboratory  in  concert  with  other  DOD 
services  and  agencies  established  a  national 
level  ATM  test  bed  known  as  the  Joint 
Advanced  Demonstration  Environment 
(JADE).  From  a  communications  perspective, 
JADE  is  a  demonstration  of  military  tech¬ 
nologies,  but  it  is  also  a  means  of  connecting 
three  service  laboratories  (Navy’s  NRaD, 
Army’s  CECOM,  and  Air  Force’s  Rome 
Laboratory)  so  that  command  and  control 
technologies  under  development  can  be  made 
to  interoperate  on  many  levels.  In  addition  to 
those  laboratories,  the  following  organizations 
are  also  part  of  JADE; 

Defense  Information  Systems  Agency's 
(DISA)  Joint  Interoperability  Test  Center 
(JITC),  Ft.  Huachuca,  Arizona.  Examples 
of  all  of  the  current  tactical  communi¬ 
cations  systems  reside  at  the  JTIC,  and 
this  enables  experiments  dealing  with 
interfacing  legacy  systems; 

Air  Force  C4  Agency  (AFC4A),  Scott  AFB, 
Missouri  where  we  will  have  access  to  the 
Air  Mobility  Command  as  a  user; 

480th  Intelligence  Group  at  Langley,  AFB, 
Virginia  (another  user);  and 
Electronic  System  Center  which  is  responsible 
for  transitioning  this  technology  into  the 
field. 

These  nodes  will  be  connected  to  several  other 
facilities  at  Rome  Lab,  including  facilities 


developing  technologies  for  automated  plan¬ 
ning  systems,  providing  access  to  and  distri¬ 
bution  of  intelligence  data,  and  a  simulated, 
distributed  Air  Operations  Center.  At  each  site 
the  communications  capacities  will  be  OC-3 
rate,  or  155  Mbps,  and  between  sites  we  have 
leased  45  Mbps  services  from  a  US  carrier; 
this  provides  a  functional  replication  of  a 
tactical  deployment  where  units  are  connected 
internally  with  wideband  fiber  and  then  are 
connected  to  external  elements  by  means  of 
lower  bandwidth  circuits. 

The  potential  JADE  offers  has  received  great 
interest  within  The  Technical  Cooperation 
Program  (TTCP)  forum  which  includes  the 
United  Kingdom,  Canada,  New  Zealand, 
Australia,  and  the  US.  A  plan  is  being 
developed  whereby  JADE  will  be  extended  to 
the  Canadian  Defence  Research  Establishment 
in  Ottawa,  Canada,  the  Defence  Research 
Agency,  Malvern,  England,  and  the  Defence 
Science  and  Technology  Organization, 
Adelaide,  Australia.  The  obvious  benefit, 
other  than  that  the  research  will  demonstrate 
international  communications  interoperability, 
is  the  demonstration  of  interoperability  among 
C2  technologies  such  as  advanced  planning 
systems.  There  is  a  great  deal  of  collaborative 
work  possible  in  getting  ATM  communi¬ 
cations  to  the  field  but  a  great  many  technical 
challenges  exist.  Joint  C2  is  another  area 
where  work  is  needed  and  JADE  has  been 
postured  to  allow  that  to  happen. 

On  a  state-wide  scale,  a  consortium  of 
industrial  research  organizations  and 
universities  has  been  formed  in  New  York 
State,  for  collaboration  on  research  in  appli¬ 
cations  enabled  by  the  emergence  of  a  future 
broadband  communication  infrastructure 
based  on  ATM.  Under  the  sponsorship  of 
NYNEX,  the  regional  telephone  service 
provider,  a  wide  area  experimental  broadband 
communications  testbed  has  been  constructed 
in  New  York  State.  Utilizing  fiber  optic 
systems  operating  at  rates  as  high  as  2.4  Gb/s 
and  the  emerging  asynchronous  transfer  mode 
switching  technology,  key  universities,  and 
research  centers  throughout  the  state  are 
linked  to  this  experimental  network  known  as 
NYNET.  Supporting  the  development  of 
novel  applications,  NYNET  is  permitting  new 
forms  of  research  collaboration  between 
academic  and  industrial  groups. 
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Now  fully  operational,  NYNET  provides 
several  important  capabilities.  First  it  provides 
remote  access  to  high  performance  computers 
located  at  several  major  universities  near 
Rome,  NY  as  well  as  some  other  locations 
still  being  investigated.  That  access  allows 
demonstration  of  the  distribution  of  data 
fusion  products  coming  out  of  distributed 
super  computers,  remote  real-time  simulation 
of  missions,  desktop  video  conferencing  for 
collaborative  battle  planning  and  decision 
making,  and  access  to  high  resolution  imagery 
to  support  target  planning  and  execution. 

NYNET  links  Cornell,  Syracuse,  New  York 
Polytechnic  and  Columbia  Universities  and 
the  industrial  research  centers  of  Brookhaven 
Laboratories,  Rome  Laboratory,  Cold  Spring 
Harbor  Research  Laboratories,  Grumman, 
and  NYNEX  together  with  NYSERNET. 
Initial  applications  planned  involve  innovative 
access  to  network  resources  to  assist  in 
economic  development  of  small  businesses, 
multimedia  networks  supporting  concepts  in 
the  medical  industry,  and  enhanced  access  to 
super-computing  centers,  thereby  facilitating 
collaborative  work  between  universities. 
Based  on  leading  edge  commercial  service 
offerings,  NYNET  provides  a  prototypical 
model  of  the  emerging  broadband  communi¬ 
cations  infrastructure.  Providing  a  unique 
affiliation  between  a  communications  com¬ 
pany,  NYNEX,  with  other  R&D  organi¬ 
zations,  applications  can  be  better  focused  on 
a  communication  model  that  will  become 
ubiquitous  in  the  near  future.  Applications 
developed  within  this  environment  can  be 
more  readily  transferred  to  industry  as  a 
result.  In  addition,  as  broadband  commercial 
services  offerings  become  more  common, 
extensions  of  the  network  can  be  more  easily 
planned.  In  fact,  the  potential  exists  to  link 
NYNEX  to  some  of  the  other  nationwide 
testbed  efforts  already  in  progress. 

NYNET  provides  an  opportunity  to  stimulate 
work  on  emerging  information  infrastructure 
opportunities  throughout  the  region  and  to 
form  collaborative  efforts  among  the  research 
organizations.  This  sharing  of  research 
resources  is  expected  to  be  a  model  of  the 
coming  information-based  society  of  the 
future.  Rome  Laboratory  will  take  a  lead  role 
in  the  development  of  a  network  management 
system  for  NYNET.  As  an  R&D  organi¬ 
zation,  not  an  operational  carrier,  Rome 
Laboratory  has  unique  capabilities  to  support 


research  in  this  area.  Topics  of  interest  will 
include;  military  to  commercial  network 
management  interfaces  and  the  use  of  artificial 
intelligence  (AI)  in  automated  network 
restoral. 

In  the  United  States,  ATM  technology  is  an 
emerging  broadband  switching  technology 
being  adopted  by  both  the  computer  and 
communications  industry.  Representing  a  new 
approach  to  managing  the  transport  of  infor¬ 
mation  across  a  network,  ATM  switching 
technology  will  equally  support  the  transfer  of 
voice,  data,  and  video  information.  It  repre¬ 
sents  a  key  technology  in  the  paradigm  of  the 
future,  commercial  information  infrastructure 
and,  as  part  of  the  NYNET  network,  will 
permit  development  of  a  broad  range  of 
applications  proposed  for  vertical  industries 
such  as  medicine,  education,  finance,  and 
small  business  development.  The  information 
infrastructure  being  stimulated  at  both  indus¬ 
trial  and  federal  levels  is  seen  as  a  critical  asset 
for  future  economic  growth.  Significant 
progress  has  been  made  in  establishing  the 
feasibility  and  in  developing  the  network 
technology  to  support  the  communications 
infrastructure.  Commercial  companies  such  as 
NYNEX  are  beginning  to  deploy  broadband 
network  systems  to  support  existing  appli¬ 
cations  such  as  LAN  interconnect.  The  future 
focus  of  research  will  be  on  new  applications 
that  will  transform  the  way  people  work,  are 
educated,  or  receive  social  services. 

7 .  Conclusion 

As  ATM  technology  matures,  it  will  provide  a 
mechanism  for  implementing  new  command 
and  control  architectures  and  procedures. 
While  the  CINC’s  staff  and  the  anchor  desks 
will  have  fiber  connectivity  in  the  local 
enclave,  they  will  also  have  more  robust 
communications  to  strategic  resources.  This 
leads  to  the  possibility  of  having  centralized 
resources,  and  a  wider  range  of  resources, 
available  to  the  CINC,  and  through  the  CINC 
to  the  CITE  and  his  staff  In  fact,  the  specific 
geographic  location  of  the  data  will  be  of 
decreasing  importance  as  the  communications 
become  more  capable. 

The  result  will  be  improved  collaborative 
planning  efforts  and  improved  techniques  for 
information  dissemination  and  distribution. 
The  result  will  be  reduced  planning  cycles  and 
improved  efficiency  in  the  use  of  forces. 
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Also,  since  the  CINC  can  also  be  connected  to 
strategic  resources  and  commanders,  the  line 
between  tactical  and  strategic  situations  may 
also  begin  to  blur  and  ultimately,  the  tradi¬ 
tional  command  structure  may  be  altered. 
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